If you pay for custom software, you should own the code, the data and the accounts it runs in. That means the repository, the hosting, the database, the CRM and the API keys all sit in your company's name, with your billing attached. The supplier gets access to work. You keep the keys. Anything else turns a paid asset into a rental you cannot move.
What owning the code and accounts actually means
Ownership has two halves, and most contracts only cover one.
The first half is legal. The intellectual property in the code transfers to your company, usually on final payment, and that is written into the scope or contract. Without that clause, the default in both the UK and the US is often that the developer retains copyright and you hold a licence. Get advice on the exact wording for your jurisdiction.
The second half is practical, and it matters more day to day. The GitHub organisation is yours. The hosting account is in your company name, on your card. The database, the domain registrar, the CRM, the email sending domain, the AI provider account and the telephony numbers are all yours.
We build everything in the client's own accounts for this reason. The client owns the code and the data. A supplier who cannot say the same sentence in writing is holding something back.
What goes wrong when the supplier holds the keys
None of these are hypothetical risks dressed up for a sales page. They are the ordinary failure modes of agency-held infrastructure.
You cannot get a second quote. If the code lives in a repository you cannot see, no other developer can estimate the work. Your only option is the price you are given.
Your data is a request, not a right. Customer records, documents and message history sit in a platform billed to someone else. Export becomes a favour, and often a chargeable one, at the exact moment the relationship has soured.
Downtime is out of your hands. A card expires on an account you cannot access. A domain lapses. You find out when a client tells you the site is down.
The build cannot be inspected. You cannot have anyone audit the security, the permissions or what the AI is actually allowed to touch, because you cannot see it.
Migration costs more than the original build. Rebuilding a working system from the outside, with no access to the code, means starting from a blank page with a live business attached.
The supplier's business becomes your risk. If they close, get acquired or simply stop replying, your operations go with them.
The ownership checklist: what to ask before you sign
Work through this with any developer or agency before money moves. Written answers, not verbal ones.
- Will the code repository be created inside our organisation, with our admin accounts, from day one?
- Who is the account holder and billing contact for hosting, the database, the domain and DNS?
- Who owns the CRM, automation platform, AI provider and telephony accounts, and whose payment card is on them?
- Does the intellectual property in the custom code transfer to us, and at what point?
- If you use your own reusable components or frameworks, what licence do we get, and does it survive the end of our relationship?
- What happens to our access on the day the contract ends? Write out the exact steps.
- Where does customer data live, and can we export all of it ourselves without asking you?
- Will we get written documentation of the architecture, the integrations and the credentials at handover?
If an answer is "we handle that for you", ask what happens when you stop working together. The answer to that question is the real answer.
Who should hold each account
| Asset | Account holder | What to check |
|---|---|---|
| Domain and DNS | You | Registrar login in your name, auto-renew on a company card |
| Code repository | You | Your organisation, your admin seat, supplier added as a member |
| Hosting and database | You | Billing in your name, you can add and remove users |
| CRM | You | You are the owner-level user, not a seat the supplier created |
| Automation platform | You | You can see every workflow and the task usage |
| AI provider keys | You | Keys issued from your account, usage visible in your billing |
| Phone numbers | You | Numbers registered to your business so they can be ported |
| Payment processor | You | Always yours. No exceptions |
| Analytics | You | Historic data stays when the supplier leaves |
How running costs work when you own the accounts
Owning the accounts means you pay the providers directly: hosting, software subscriptions, phone minutes and AI usage come out of your accounts, not through a supplier markup. That is usually cheaper, and it is always clearer.
It does mean you see the bills. Usage-based tools can surprise you if nobody is watching. Zapier, for example, counts each successful action step as a task, while triggers, filters and paths do not count, and at the plan limit new runs are held until you pay for more tasks (Zapier help centre). Ask your developer for an estimated monthly running cost per tool before the build starts, and put a usage alert on anything metered.
Subscription creep is a real cost of not owning your stack. TMMB Academy came to us with a fragmented funnel, rising software subscriptions and no single system. The fix was one portal with role-specific workspaces for admins, coaches, creators, sales, assistants and brands, built to be theirs. The TMMB Academy case study covers what that included.
Support when you own everything
A fair objection: if the supplier does not hold the keys, what stops them walking away?
Nothing. That is the point. Support should be something you choose to keep buying, not something you are locked into because you cannot leave. Our Run and Improve retainers are Care, Improve and Scale at £1,000, £2,000 and £4,000 monthly (US $2,000, $3,500 and $6,000), with a three-month minimum and then monthly with 30 days notice. They are optional and priced separately from the build.
Handover is what makes that work. Documentation, trained staff and a staged launch mean another developer can pick the system up. We also moved our own CRM off GoHighLevel into a system we built, which is a useful exercise in finding out how portable your own stack really is.
When supplier-hosted is a reasonable trade-off
Owning everything is not always right. If you are buying a genuine off-the-shelf product, you are buying a subscription, and the vendor hosting it is normal. Compare that honestly against a build using custom software versus SaaS.
Supplier-hosted custom work can also make sense for a short pilot you expect to throw away, or when you have nobody who can hold an admin account responsibly. In both cases, agree the exit terms in writing first.
Do this week
Open a document and list every system your business runs on. Next to each one, write the name of the person who can log in as administrator and the card the bill goes to. Anything where that is not someone inside your business is a dependency you did not choose.
If the list worries you, our approach starts with an audit that maps exactly this, and a written scope follows. Get in touch if you want a second opinion on what you actually own.
