Building systems that scale without collapsing.
I help startups move fast without accruing irreversible technical and organizational debt — by combining strong engineering fundamentals with product judgment.
I approach engineering with a bias toward action, but not recklessness. Ship early, iterate based on real feedback, and never let perfect be the enemy of deployed. But speed without discipline is just chaos — every system I build has proper security, testing, and observability from day one.
My background spans fintech compliance at GÜENO, nonprofit tech at GoFundMe, and various B2B SaaS products. This exposure to different domains taught me that good engineering principles transfer: type safety, defense in depth, designing for failure modes, and always understanding the business context behind technical decisions.
I don't just build what's specified — I question requirements, propose alternatives, and optimize for long-term maintainability over short-term convenience. Technical decisions are organizational decisions. Infrastructure choices affect team velocity, cognitive load, and how quickly you can respond to market changes.
GoFundMe Hackathon Winner
Built the winning project that shipped to production. Demonstrated ability to move fast and deliver impact.
NPO Claim Flow
Designed, engineered, and developed the new nonprofit organization claim flow at GoFundMe. End-to-end ownership.
I optimize for reversibility before elegance. The best architecture is the one you can change when requirements shift. Premature optimization and over-abstraction both poison future flexibility.
I bias toward boring technology until scale forces otherwise. Postgres, Redis, and monoliths solve most problems. Microservices, event sourcing, and novel databases are solutions to specific constraints — not default choices.
Infrastructure decisions are organizational decisions. Choosing a monorepo vs multi-repo, monolith vs microservices, or sync vs async affects team structure, deployment velocity, and cognitive load. Technical choices have human consequences.
I design for failure modes before happy paths. What happens when Redis is down? When a migration fails halfway? When a user bypasses the UI? Systems that only work under ideal conditions don't work.
Speed matters — but only when it doesn't poison the future. Shipping fast is valuable. Shipping fast in a way that makes the next feature harder is debt. I choose speed that compounds, not speed that extracts.
TypeScript, JavaScript, Java, Kotlin, Next.js, React, Node.js, NestJS, Spring Framework, PostgreSQL, MongoDB, Redis, Drizzle ORM, AWS, testing (Jest, Vitest, Playwright), CI/CD, Docker, monorepo tooling (Turborepo, pnpm workspaces), infrastructure fundamentals. And a lot more.
Most of my work lives at the intersection of product, systems, and scale. If this way of thinking resonates, you'll find me on LinkedIn.
Connect on LinkedIn