You do, from day one — no lock-in, no hostage repositories. The repository sits in your organisation and the accounts are registered to you.

What happens if we stop working together?

Nothing has to be transferred, because nothing was ever held. You keep the repository, the accounts, and the infrastructure, plus the docs a new team needs to continue.

Do you build on a proprietary framework of your own?

No. The stack is mainstream and deliberately boring, so any competent team can maintain it without learning something only we know.

What is actually in the repository at handover?

Readable code and commit history, tests covering the paths the business depends on, a README that gets a new engineer running locally, and notes on the non-obvious decisions.

Operating fact 03

You own the result

The code, the repository, the accounts, and the infrastructure are yours from the first commit — not released to you at the end if the relationship goes well.

Get it built

Ownership starts at the first commit

The repository lives in your organisation. The cloud accounts, the domain, the database, and the third-party services are registered to you and billed to you. We work inside your accounts with access you grant and can revoke, which means there is never a moment where the thing you paid for is somewhere you cannot reach.

This is deliberately unromantic. Ownership that depends on goodwill is not ownership — it is a hostage situation everyone is being polite about.

What a clean handover contains

A repository someone else can read: conventional structure, no dead branches, commit history that explains itself. Tests that cover the paths the business depends on, so a future developer can change things without guessing what they broke. A README that gets a new engineer running locally without asking us anything, and documentation for the decisions that are not obvious from the code — why this queue, why this data model, what the third integration is actually for.

Infrastructure as configuration rather than as something that was clicked into existence once. And no framework of ours in the middle of it: the stack is mainstream and boring on purpose, so the pool of people who can maintain it is the whole industry rather than us.

Why so many builds end up owned by the builder

Rarely through malice. It happens through accumulation — the staging server that only one person can reach, the deploy that runs from someone's laptop, the proprietary admin layer, the config that lives in a chat message. None of it was a plan. Together it means that leaving costs more than staying, and you find out only when you try.

The test is simple, and worth applying to whoever you hire: if you ended the engagement this afternoon, could another team pick the project up on Monday? If the answer needs a paragraph of explanation, you do not own it yet.

What you get

A product that survives us. If you hire your own team next quarter, they inherit an asset with a readable history instead of a liability with a phone number attached. If you raise money, technical diligence goes through a repository built to be read. And if you want to keep working with us, that stays a decision rather than a dependency.

Describe what is stuck at /start and an engineer replies within one business day with a scoped plan — including what the handover would contain.

Frequently asked questions

The other operating facts

That's the deal. What's the project?

Three minutes at /start: describe what's stuck. An engineer replies with a scoped plan within one business day — not a sales call.