Here is a question most founders never think to ask until the day it really matters. If the person who built your systems walked away tomorrow, could you still run your business?
For a lot of growing businesses, the honest answer is no. The website, the client portal, the automations, the onboarding flow, all of it was set up by a contractor or an agency, and it works beautifully right up until you need to change something or the relationship ends. Then you discover that you do not actually own your business systems. Someone else does. And they are the only one who can touch them.
This is one of the quietest and most serious risks a business can carry. It does not show up on a profit and loss statement. It does not slow you down on a normal day. It just sits there, invisible, until the day you try to make a change, part ways with the person who built it, or scale past what the current setup can handle. Then it becomes the only thing that matters.
What it really means to own your business systems
Owning your business systems is not the same as paying for them. You can be paying every month for the software, the hosting and the maintenance, and still not own the thing that runs your business.
Real ownership means a few specific things. The accounts are registered to you or your company, not to a contractor’s personal login. The code and the automations live somewhere you can access, edit and hand to someone else. Your data belongs to you and flows where you decide it flows. And critically, none of it depends on one specific person being reachable, willing, and on good terms with you.
When those things are true, a contractor is someone who helps you build and improve. When they are not true, that contractor becomes a single point of failure with a lot of power over your business. This is what the software world calls vendor lock-in, and it is far more common in small and growing businesses than most owners realise, because the setup usually happens early, fast, and on a handshake.
The warning signs you do not own yours
You do not need to be technical to spot the risk. The signs are usually plain once you know to look.
The first is whose name is on the accounts. If the app that runs your business is registered under a contractor’s own developer account, you may have no way to transfer it, even if you paid for every hour of the build. The second is where the alerts go. If the internal notifications your business relies on are wired to someone else’s email address, then someone else is quietly at the centre of your operations. The third is whether you can change anything yourself. If the workflows are locked or protected so that only the original builder can edit them, you are renting your own business back from the person who set it up. And the fourth is whether your data can move. If information only flows one way, into a spreadsheet that never feeds back, then you have a system that captures but does not connect, and you are filling the gaps by hand.
None of these are dramatic on their own. Together, they add up to a business that cannot be changed, fixed or scaled without one specific person’s cooperation. That is key person dependency, and it is a risk worth taking seriously before it forces your hand.
A real rebuild, from locked to owned
Here is how this played out for one business, with the details changed to protect them.
The company is a patient education platform that serves dental and airway clinics. Every clinic it signs up gets its own branded portal. It is a strong product with real demand. The problem was underneath. The entire delivery system had been built by an outside contractor, and when that working relationship broke down, with lawyers involved, the business found itself in a difficult spot. It could keep selling. It just could not build, fix or scale anything without the very person it was trying to move on from.
When we looked closely, the specifics were worse than they first appeared. The app that set up every new clinic was registered under the contractor’s own developer account, and that type of account cannot be transferred. The core workflows were protected and hardcoded to a single clinic, so nothing carried over to the next one. Every internal notification was pointed at the contractor’s own inbox. And the onboarding form wrote one way into a spreadsheet and never back, so client contracts could not fill themselves in. On top of all of that, onboarding a single clinic took around eight hours of manual work, and there was a fixed webinar launch date coming fast.
Rather than patch the setup we had inherited, we rebuilt the onboarding engine as one pipeline that the client fully owns, starting with a single source of truth. Here is what that looked like.
We built a client owned provisioning app, a private application registered under the client’s own developer account and connected securely, scoped to do exactly what setting up a clinic needs and nothing more. We made a proper database the single source of truth, holding every clinic’s onboarding record, its secure access token, and a place for clinic logos, all locked down with the right permissions. We moved the setup logic to serverless automation that creates the clinic account, pushes the standard setup, wires the menu, generates the branding, and sends the notification, all from a single trigger. We rebuilt the forms so they write both ways, so information flows back into the right fields automatically and contracts fill themselves in instead of being retyped. We rebuilt eleven locked, single clinic workflows into one clean master setup that every new clinic inherits as a working system. And we wrote the whole thing up as a documented standard operating procedure the client can hand to any future operator.
What changed
Once the rebuild was live, onboarding a clinic dropped from around eight hours of manual work to about ninety minutes. Eleven workflows that had been locked and stuck to a single clinic were rebuilt clean and reusable across every clinic. And most importantly, the client now owns one hundred percent of the infrastructure: the developer account, the app, the code and the data. Everything runs from a single source of truth that the business controls.
The real win is not the time saved, welcome as that is. It is that the business is no longer held hostage by its own setup. It can onboard the next clinic without the original contractor, change what it needs to change, and grow without asking permission from someone it no longer works with. The webinar launch went ahead on schedule, on infrastructure the client owns outright.
How to protect your own business
You do not need a crisis to check where you stand. A calm afternoon is enough.
Start by writing down every tool and system your business depends on to serve customers. For each one, ask four simple questions. Whose name is the account in? Who can edit it if something breaks? Where does the data live, and can I get it out? And could I hand this to a new person tomorrow without the original builder’s help? Anywhere the answer makes you uneasy is a spot worth fixing before it becomes urgent.
The good news is that this is fixable, and usually without starting from zero. Ownership can almost always be rebuilt onto infrastructure you control, one piece at a time, while the business keeps running. The trick is to do it on a quiet week by choice, rather than on a deadline because a relationship went sideways.
If you have a feeling that too much of your business lives on someone else’s accounts, or that one person leaving would leave you unable to run things, that is worth acting on. You can book an Ops Review and we will map what you own, what you do not, and what it would take to get the keys back in your hands.
