A lot of studios say you will own your software. Fewer can tell you what that sentence means when you press on it, and fewer still build in a way that makes it true. Ownership is not a licence clause or a copy of the source dropped in a folder at the end. It is a property of the system: the degree to which someone who is not us could operate it, change it, and extend it without needing us in the room.
That definition is useful because it is testable. You do not have to take ownership on faith — you can ask what would actually happen if we disappeared, and a good answer is the same as a true one. This note is the test we hold our own work to, and the practices that let it pass.
Ownership is a test, not a clause
The honest test of ownership is a hypothetical you should be allowed to ask out loud: if this studio vanished tomorrow, could a competent engineer you hire next month run the system, understand why it is built the way it is, deploy a change, and add a feature — using only what was handed over? If the honest answer needs an asterisk that points back at us, you do not own it yet; you are renting it with extra steps.
Everything below exists to make that answer a clean yes. Not because we plan to disappear, but because a system that survives our disappearance is, by definition, one you genuinely control — and the discipline that gets it there is the same discipline that makes it good.
Documented to be handed over, not to look thorough
Documentation written to impress is a wall of text nobody reads. Documentation written to be handed over is different in kind: it records the decisions and the reasons behind them, so the next engineer inherits the "why," not just the "what." The code already says what it does; what it cannot say is why this approach was chosen over the obvious alternative, and that is exactly the knowledge that walks out the door when a project changes hands.
So we keep short, dated decision records alongside the code — each one a context, a decision, and its consequences — plus the runbook a new operator needs to deploy, configure, and recover the system. These are deliverables, not afterthoughts, written as we go rather than reconstructed from memory at the end.
# ADR 0007 — Analytics & consent Status: accepted Context: we need product analytics without shipping a consent liability. Decision: first-party + consent-gated; no third-party beacons by default. Consequences: more wiring up front; no surprise in a KVKK/GDPR review later.
No lock-in we quietly benefit from
A subtle way to undermine ownership is to build on foundations that only the builder can maintain — a bespoke framework, an undocumented deployment that lives in one person’s head, a dependency on a service you are not told you depend on. None of it looks like a trap; all of it means you cannot leave. We treat that as a defect, not a retention strategy.
The practical version is boring and deliberate: standard, well-understood tools a competent team can hire for; infrastructure described in the repository rather than clicked together by hand; secrets and configuration documented and held by you. If the relationship ends, nothing technical holds you hostage — which, not incidentally, is the strongest reason to keep a relationship that is working.
The cold-start test
The way we check all of this is to run the cold start: a person who did not build the system, given only what was handed over, gets it running and ships a small change. It is the same logic as the performance budget and the typed-content gate — the property you care about should be something a fresh pair of hands can verify, not something the original authors assure you is fine because they already know it by heart.
When the cold start is rough, the handover was incomplete, and we fix the documentation rather than explain the gap over a call. The point is to make us unnecessary to the running of your system — that is what the word "own" is supposed to mean.
Where this is honest about its limits
Ownership does not mean you should never need an engineer again, and it would be dishonest to imply it. Software is living; it has dependencies that age, platforms that change underneath it, and new things you will want it to do. What ownership gives you is the choice — to maintain it yourself, to hire someone, or to keep working with us — instead of having that choice made for you by lock-in.
That is the difference we are actually selling: not software you will never touch again, but software whose future is yours to decide. Keeping us is then a decision you make because the work is good, not one the architecture made for you.