The whole product, one owner
For a founder who needs a product built, not a team to manage. One senior engineer takes the data model, the backend, the interface, the payments, the content layer your team edits and the deploy. Performance, accessibility and search checks run inside the build as gates that block a merge, so there is no clean-up pass at the end.
The gates named in the scope block a merge that fails them, and they pass on the build that ships.
A donation platform on Fastify and PostgreSQL, in production, with AmeriaBank vPOS 3.1 and encryption at rest
The bar the build has to clear
Two shapes, and you pick before anything starts. A fixed scope, where the feature list and the acceptance criterion are written and approved first and the work is measured against them. Or a named-owner engagement, where I own the product's engineering over a period and the scope is re-agreed as the product learns. Both carry the same list below.
- The gates named in the scope block a merge that fails them, and they pass on the build that ships.
- Every flow in the scope works end to end on a production build, including the failure paths.
- The content layer is editable by a non-developer on your side before handover.
- The code, the deploy and the documentation are handed over in full, yours to the last line.
What you get instead of a team to manage
One person answers for the whole thing
A product your team can run without me
Payments and data handled like they matter
Speed, accessibility and search are gates, not a later pass
What lands in your repository
- The scope document, carrying the feature list, the gates and the acceptance criterion, approved before the build.
- The product: schema, API, interface, payments and the content layer, in your repository.
- The CI workflows that run the checks: tests, end-to-end smoke, accessibility, Lighthouse budgets, structured-data validation.
- A decision record, so the reasoning behind each choice is readable a year from now.
- Deploy documentation: environments, variables, migrations, rollback.
- A walkthrough session with the people who will run it, technical and editorial.
What I would not build
Who this is for
You are a founder or a CTO with a product to build and no engineering team to build it, or a team already full for the next two quarters. Agencies quote you a project manager, two contractors and a handover date. What you want is one person who can hold the whole thing in their head: the database, the payment flow, the admin your editors will actually use, and the deploy that has to survive a Friday. That is this.
How the work runs
The scope is written first. I put down what the product does, which flows are in, which are out, what the content layer has to let your team edit, and the gates the build ships behind. You approve it in writing. From there, either the scope is fixed and the work is measured against it, or I own the product's engineering over a period and we re-agree the scope as the product learns what it is. Both shapes carry the same acceptance criterion, and you pick the shape before anything starts.
Then I build in your repository, on branches you can read. The checks run from the first week, not the last: tests, an end-to-end smoke run, accessibility, Lighthouse budgets, structured-data validation. They are merge gates, which means a commit that breaks one does not land. The reason is plain. Speed and accessibility added at the end are a project of their own, and they decay the moment someone ships a hurry.
Payments get built against the provider's own specification and tested end to end, including the paths where the bank says no. Personal data is encrypted at rest. Every non-obvious decision goes into a written record, so a year from now your engineers can read why the schema looks like that.
At handover you get a walkthrough for the engineers and a second one for the people who edit content. The code is yours to the last line.
Best fit
Best fit if one person on your side can approve a scope and answer questions inside a working day, and if the product has a user you can name. If the product already exists and the question is why it is slow or invisible to search, say so in the first message. Those checks are part of this build, and I would rather scope the smaller job.
What was measured on the last builds
I built Teach For Armenia a bilingual site on Next.js and Sanity: 16 pages, 2 locales, 61 content schemas, counted in the repository at commit a86a314. The Armenian type scale was set from measured x-height rather than borrowed from the English one. Read the Teach For Armenia case.
For the same client I built the donation platform solo, on Fastify and PostgreSQL with AmeriaBank vPOS 3.1 and encryption at rest. It launched in 2026 and runs in production. Read the donation platform case.
The commerce platform I own and still run is the one I point at when someone asks whether the gates hold under a real codebase: 1,059 commits since March 2026, seven CI workflows, and accessibility, search and best-practice scores that block the merge instead of decorating a report. Read the commerce case.
I built the Armenia Education Initiative a bilingual site on Payload CMS, with a multi-step application form and anti-spam on the submission path.
If you are hiring
I am also open to a full-time remote role. If that is what you are staffing, send me the details.
The cases behind these numbers
1,059 commits since March 2026 on a commerce platform I own and still run, with seven CI workflows and merge gates that block a failing build
16 pages, 2 locales and 61 content schemas on the Teach For Armenia site
Tell me what the product has to do
Send what you are building and the deadline behind it. I come back with the scope, the gates it ships behind and what you own at the end.