About
One person, start to finish.
No handoffs between a designer, a developer, and an account manager — which is where most of the cost and nearly all of the misunderstanding lives.
I spent three years at a consultancy in Berkeley delivering work across about thirty client engagements — integrations, internal tools, document pipelines, scheduling systems. Some of them I built with a team. Plenty of them I owned end to end, from the first call with a stakeholder to the thing running in production.
In 2026 I went independent, doing the same work directly. The difference is not the engineering. It is that there is nobody between the person with the problem and the person solving it, which removes a translation step that quietly costs more than anything else on a small project.
How I work
Discovery before a number
A fixed price quoted before anyone has looked at the system is a guess, and the person who pays for a bad guess is always the client — either in money or in the corners that get cut to protect the margin. Discovery is two or three weeks, it produces a written plan and a real quote, and the plan is yours whether or not you hire me for the build.
Something to look at, every week
There is a staging URL from the first week and something new on it every week after. Not a status email — the actual thing, in a browser, that you can click. It is the only progress report that cannot be wrong.
The handover is written while it is fresh
Documentation reconstructed from memory six weeks after the fact is worth roughly nothing, and everyone involved knows it at the time. I write it as I go, and it ships with the work rather than after the invoice.
I stay accountable after launch
The interesting part of a project ends at launch and the expensive part starts there. A retainer exists so there is someone who already knows the system when something breaks at an inconvenient hour.
I will tell you when you don't need me
If a template, an off-the-shelf tool, or a smaller piece of work would serve you better, that is what I will say — and I will name the one I would use. Turning work away costs me a project and saves you one you would have regretted.
The three ways to pay for that — discovery, a fixed-scope project, or a retainer — are set out on the services page, including what each one does not include.
What I build with
Tools are a means, and this list changes. What does not change is the preference for boring, well-understood pieces over interesting ones — you inherit whatever I choose here, and you should be able to hire someone else to work on it.
- Day to day
- TypeScript and Python. React and Next.js on the front, Node and Express or plain Python services behind them, PostgreSQL underneath more often than not.
- Running it
- Docker for anything that has to behave the same twice, deployed to a managed platform where that is the cheaper answer and to EC2 behind Nginx where it is not. CI that runs the tests and refuses to deploy when they fail.
- AI, where it earns its place
- Extraction and retrieval pipelines against the Anthropic and OpenAI APIs — the kind of work that turns five hours of manual document review into four minutes, with a confidence score and a source reference on every answer so a person can check the machine rather than trust it. I am not interested in adding a chat box to something that does not need one.
- Integration platforms
- Quickbase, Airtable, Workato, n8n, Zapier and Make. Most businesses already run on some of these, and the honest answer is often to make the existing thing work properly rather than to replace it with something bespoke.
This site is the example
Every performance number published here was measured on the build that is actually serving you, and the deploy fails when one of them regresses. The case study explains how, including the two checks that turned out to be measuring nothing.