How I work
Architecture decisions are operational decisions. Multi-tenancy, flaky networks, partial data, and slow connections are not edge cases; they shape what the system actually has to handle. I work close to the schema, the boundaries, and what breaks first, then let the rest of the product follow.
I have shipped early prototypes, internal tools, and platforms that had to keep running after the launch attention faded. What stays consistent across all of them is structure: fewer moving parts, RLS where it belongs, and abstractions only when they earn their place. Software you can read and change years later, not just demo once.
Who I work with
Founders, CTOs, and product teams at startups or operational businesses who care about clear structure and need systems that scale without rewrites. I take ownership of the call when it matters, push back on shortcuts that compound later, and treat the product like I will still be on call for it next year.
Rhythm
Long-form thinking takes calm, so I keep my schedule simple on purpose. The same instinct shows up in how I build: fewer pieces, fewer surprises, and decisions documented once instead of reopened every quarter.
Not a guru, not a hacker, not a visionary.
Someone who designs the boundaries, owns the trade-offs, and keeps the system honest after the launch.