Yes: your repositories, your cloud and model accounts, documented for whoever picks it up. Ownership is set up that way at the start rather than transferred at the end, so there is never a moment where a handover is a negotiation.

What stack do you build on?

TypeScript end to end, React on the front, Node and Postgres behind it, deployed in Europe. The bias is deliberate: one language across the whole system, and boring, widely-known technology, because the point is that someone else can maintain it.

Can our own developers take it over later?

That is the design goal. The codebase carries its own map and the reasoning behind the load-bearing decisions, and the conventions are enforced by checks that run before anyone reviews anything, so a new developer inherits the rules with the repository instead of learning them by breaking them.

How long does a first version take?

About a week, for a focused product with one main flow and real accounts. The honest predictor is not the feature list, it is how many other systems it has to integrate with: every integration carries somebody else's schedule inside it, and that is what turns a week into a quarter.

Where does it run, and does data leave the EU?

It runs in Europe by default, and which third parties receive what is written down rather than assumed. For AI features specifically, model provider choice is where residency actually gets decided, so it is a scoping question rather than a deployment detail.

Service 04 / 06

The demo works. Now it has to become a product.

This is the app around the AI: sign-in, roles and permissions, payments, the admin screens nobody demos, and a deployment that survives a real customer. Most AI projects do not fail at the model; they stall at the eighty per cent of a product that has nothing to do with the model.

What I build

The full app: interface, back end, database, deploys
Accounts, roles and permissions that survive a real customer
The boring screens nobody demos: admin, billing, settings, audit
Written to be handed over, not to keep me employed

What you get

A product you own outright: your repos, your accounts, documented for whoever picks it up.

Good fit ifyou need the whole thing built, not a model dropped into an app you already have.

What "the whole product" actually includes

Everything between a working prototype and something you can sell to a stranger. The list is unglamorous and it is where the months go.

The interface people use, on a phone as well as a laptop.
Accounts, sessions, roles and permissions that hold up when the second customer arrives.
Billing, or at least the seam where billing will attach without a rewrite.
The admin side: who used what, what it cost, what went wrong, and the screens to see it.
Data protection as engineering rather than a page: export, deletion, retention that actually runs on a schedule.
Deployment, backups, error reporting, and a way to ship the next change safely.

Why the boring screens decide the project

Because they are what your team lives in after launch. A product with a beautiful main flow and no admin view generates a support request for every edge case, and those land on the people who can least afford them.

This site is the reference implementation of that opinion, and it is public: the parts a visitor sees are a fraction of it. Behind them are an owner's dashboard, per-conversation cost accounting, spend ceilings that refuse work rather than surprise you, scheduled retention jobs, and an audited path for reading anything private. None of it demos well. All of it is why the thing can be left running.

Built to be handed over

One engineer building your whole product is a risk, and the mitigation has to be structural rather than a promise. The mitigation is that the codebase is written for the next person from the first commit: the decisions are documented where the code is, the conventions are enforced by checks rather than by memory, and the whole thing runs on a stack your next hire has already used.

You own the repositories and the accounts throughout. If we stop working together, nothing about that changes, which is the only version of this arrangement worth signing.

When this is the wrong service

If you already have an engineering team and a product, and you need an AI capability added to it, you do not need this: you need the agent, retrieval or voice work dropped into what you already run. This service is for when the surrounding product does not exist yet, or exists as a prototype that cannot take a paying customer.

Questions people ask

Do we own the code?: Yes: your repositories, your cloud and model accounts, documented for whoever picks it up. Ownership is set up that way at the start rather than transferred at the end, so there is never a moment where a handover is a negotiation.
What stack do you build on?: TypeScript end to end, React on the front, Node and Postgres behind it, deployed in Europe. The bias is deliberate: one language across the whole system, and boring, widely-known technology, because the point is that someone else can maintain it.
Can our own developers take it over later?: That is the design goal. The codebase carries its own map and the reasoning behind the load-bearing decisions, and the conventions are enforced by checks that run before anyone reviews anything, so a new developer inherits the rules with the repository instead of learning them by breaking them.
How long does a first version take?: About a week, for a focused product with one main flow and real accounts. The honest predictor is not the feature list, it is how many other systems it has to integrate with: every integration carries somebody else's schedule inside it, and that is what turns a week into a quarter.
Where does it run, and does data leave the EU?: It runs in Europe by default, and which third parties receive what is written down rather than assumed. For AI features specifically, model provider choice is where residency actually gets decided, so it is a scoping question rather than a deployment detail.

Ask my AI about this