About me

I started as a self-taught developer building small websites for local businesses, which taught me an unglamorous but important lesson early on: the client does not care about your framework choice, they care about whether their site works, loads fast, and helps them get customers. That lesson has stuck with me through every job title since — junior developer, senior engineer, staff engineer, and now independent consultant.

Over nine years, I moved from building marketing sites to full product engineering: authentication systems, payment infrastructure, real-time dashboards, and eventually AI-powered features as large language models became reliable enough for production use. Each stage added tools to the same underlying discipline — understand the problem deeply before writing code, and prefer the boring, well-understood solution over the exciting new one unless the exciting new one is genuinely necessary.

My work today splits roughly into three categories. The first is greenfield product engineering — taking a founder's idea and a rough set of requirements and turning it into a production SaaS MVP, complete with authentication, billing, and the core feature set that proves out the business hypothesis. The second is fixing and improving existing systems: performance audits, legacy migrations, and the kind of debugging that requires patience more than cleverness. The third, and increasingly the most interesting, is AI feature integration — chatbots, retrieval systems, and autonomous agents built with the same production rigor as everything else, rather than treated as a separate, experimental category of software.

Across all three, my day-to-day toolkit is React, Next.js, and TypeScript on the frontend; Node.js, PostgreSQL, and Prisma or Drizzle on the backend; React Native when a product needs a native mobile presence; and LangChain or LangGraph when a product needs genuine AI reasoning rather than a thin wrapper around a single API call.

Most clients come to me after a bad experience — a freelancer who disappeared mid-project, an agency that delivered generic boilerplate, or an internal team stretched too thin to take on one more initiative. What they consistently tell me they value most is not raw technical skill, which is table stakes at the staff engineer level, but communication: a written proposal before work starts, visible progress throughout, and an honest answer when something is going to take longer than expected, rather than silence until the deadline arrives.

I also try to leave every codebase better than I found it, even when that was not explicitly part of the brief. A small refactor here, a missing test there, a README that actually explains how to run the project — these compound over time into a codebase your next hire can actually work in, which is a form of professionalism that outlasts any single feature I ship.

I write about the engineering decisions I make on real projects, because the internet has enough generic tutorials and not enough honest accounts of what actually happened when a performance fix met a real production system. I also spend time contributing small fixes to open-source libraries I rely on daily — partly as a way of paying down the debt every developer owes to the tools we did not have to build ourselves, and partly because reading other people's production code is one of the fastest ways to stay sharp.