Approach
How I think about building software — and what it's like to work with me on a team.
Engineering Principles
Understand the problem before writing code
I start with constraints, not solutions. What does the system actually need to do? What are the failure modes? What decisions need to happen at the architecture level before anyone opens an editor?
Architecture before interface
Data models, API boundaries, auth patterns, deployment strategy — I think about these first. A well-architected system makes everything downstream easier: features ship faster, bugs are shallower, onboarding is smoother.
Ship in working increments
I build in vertical slices — real, working software at every step, not wireframes followed by months of silence. This keeps the feedback loop tight and surfaces problems early.
Leave the codebase better than I found it
Clean code, clear naming, meaningful tests, documentation where it matters. The goal is a system the next engineer can understand and extend without a guided tour.
Tools & Workflow
Current stack
React / React Router, NestJS, PostgreSQL, MongoDB, Directus CMS, Medusa (headless commerce), Stripe, Docker, Tailwind CSS, TypeScript across the board. Python, FastAPI, and PyTorch on the side.
On AI-assisted development
I use AI tools throughout my workflow — research, code generation, testing, documentation. It's a multiplier, not a replacement. The architecture, system design, and engineering judgment are mine. The tools I use to execute are whatever gets the best result.
What this means for a team
Higher throughput without sacrificing quality. I move fast because I've invested in tooling and patterns that let me — not because I cut corners.
Where I Thrive
- Small teams where engineers own features end-to-end
- Codebases that value clarity over cleverness
- Product-minded engineering — understanding why, not just what
- Environments where shipping matters more than process theater
Sound like a fit?
I'm looking for my next role. Let's talk.
Get in touch