3 min read
Built on your accounts: why ownership matters

There is a clause in a lot of build work that never gets said out loud: the thing made for you is not actually yours. It sits on the builder's platform account, under the builder's logins, with the data somewhere you have never seen. None of that feels like a problem while the relationship is good. It is the ending that costs you.
What “your accounts” means in practice
Everything we build is set up in your name, paid on your card, with you as the owner and us added as a user. Concretely, that is:
- The domain and the DNS behind it, registered to you, so nobody else controls where your name points.
- The website or landing-page platform — your project, your billing, your export button.
- The automation tools and AI subscriptions the systems run on: your workspace, with our access sitting alongside yours rather than above it.
- The inbox, calendar, sheets and CRM the work touches — the accounts you already use, not a copy we keep.
- The content and the records the systems produce, in your storage, in a format you can open without us.
It is a slower way to start. It means asking you for a card at the beginning instead of the end, and it means the first hour of a build is often admin rather than anything you can look at. We think that is a fair trade for never having to unpick it later.
The test
If we stopped working together tomorrow, would it keep running?
That is the only ownership question worth asking, and it has a yes-or-no answer. Built this way the answer is yes: nothing needs migrating, nothing switches off when the invoices stop, and no part of your business is sitting with somebody else as collateral. Built the other way, the answer is a negotiation.
What it costs us to work this way
It is more work on our side, and it is worth being straight about that. We set things up inside constraints we do not control. We cannot keep one tidy account and run everyone through it. When a platform changes its pricing or its permissions we deal with it in your workspace rather than in ours. We also give up the quiet leverage that comes from holding the keys — which is the part that matters most, and the reason we do it.
What to ask anyone who builds for you
This is not a question only for us. Ask it of us and of anyone else you are considering, and ask before the work starts, because the answers are far harder to change afterwards.
- Whose name is on the accounts, and whose card pays for them?
- Where does the data live, and can I export it without you?
- If we stop working together, what switches off?
- What am I handed at the end: logins, documentation, or a phone number to call?
- Who else has access, and can I remove it myself?
A straight answer to all five is a good sign, whoever gives it. A vague answer is also an answer.
Handoff is part of the build, not a favour
Ownership on paper is not ownership if nobody has shown you how the thing works. Every engagement ends the same way: a walkthrough of everything built, written documentation your team can follow without us, and a support window for the questions that only turn up once it is running. After that you can keep us on, replace us, or run it yourself — and none of those three should be a difficult conversation.
It is also why the opportunity summary names the tools it recommends instead of describing them vaguely. You should be able to read the plan, look up what it runs on, and know exactly what you would be signing up to own.



