Most owners who ask about outsourcing software are not really asking about money. They have already done that arithmetic. What they are asking, usually without saying it, is a different question: if I hand this over, can I ever get it back?
It is a fair worry. The failure mode is real and common. A company hires a firm, the firm builds something that works, and two years later the accounts are in the firm's name, the code is on their servers, nobody internally understands how it runs, and the renewal conversation is not a negotiation. That is not outsourcing. That is a hostage situation with an invoice attached.
The good news is that the whole thing turns on about six decisions, all of which you make at the start, and none of which are technical.
Own the accounts, whoever writes the code
The single highest-leverage rule: every account is in your company's name, with your billing, and you hold the admin. Cloud hosting, the domain, the repository, the error tracker, the analytics, the email sender. Your partner gets invited into them.
This sounds obvious and is violated constantly, usually for a convenient reason early on. Someone needs a server today, the agency has an account, it goes there, and nobody revisits it. Four years later that server is the business.
The test is simple. Ask what happens to each account if the relationship ends on a Friday. If the honest answer for any of them is "we would have to ask them," fix that one first.
Own the code, and know where it is
You want two things in writing. An assignment clause saying work product belongs to you on payment, and a repository in your organisation that you can see today.
The second one matters more than people expect, because assignment language is only as good as your ability to take delivery. I have seen contracts with perfect IP terms attached to code nobody outside the vendor had ever seen. If you cannot browse the repository this afternoon, you do not functionally own it yet.
One nuance worth knowing: the chain has to reach the individuals. If your partner uses subcontractors, their agreement with those people needs assignment terms too, or there is a gap between you and whoever actually typed the code. This is a named deal-blocker in acquisitions, and it surfaces at the worst possible time. Our guide to vetting a development partner with a global team goes into the diligence questions in more detail.
Keep the decisions, delegate the building
Here is the distinction that keeps owners sane. You are not outsourcing judgement about your business. You are outsourcing the construction.
In practice that means you own what gets built and why, in what order, and what "done" means. Your partner owns how, the estimate, and the delivery. When those blur is when people feel out of control, and it usually blurs in one specific way: the roadmap starts being set by what is technically interesting or convenient rather than what the business needs next.
A concrete guard: a one-page list of the next three things and why, reviewed monthly, written in business terms. If your partner cannot explain what they are building in language your bookkeeper would understand, that is not a communication problem, it is a sign nobody has connected the work to an outcome.
Insist on documentation you can read
Not architecture diagrams. A runbook: how to deploy, where things live, what to do when it breaks at 6pm, who to call at each vendor. Written for a competent stranger, because a competent stranger is exactly who will read it if your partner disappears.
Ask for it at the first milestone rather than at the end. Documentation written at the end is written for the exit; documentation written throughout is written for the work, and it is far better.
Agree how it ends before it starts
The most reassuring paragraph in any development agreement is the one describing an orderly exit. A notice period, a defined handover (credentials, documentation, a walkthrough, a support window), and no charge for delivering what is already yours.
A partner who resists this is telling you something, and a partner who offers it before you ask is also telling you something. We put ours on the table early for exactly that reason: an engagement someone cannot leave is not a partnership, it is inertia, and inertia is a bad reason to keep working with anyone.
Keep one person internally who understands the shape
You do not need an engineer on staff. You do need one person, often the owner in a smaller company, who can answer: what systems do we have, what does each one do, where does it live, and who touches it.
That is an afternoon of documentation and a monthly half-hour of upkeep. It is also the difference between delegating and abdicating.
What this means for your business
- Audit account ownership this week. Domain, hosting, repository, analytics, email. Anything not in your name is the first thing to move, and it is usually a ten-minute job that nobody has scheduled.
- Get the repository visible to you now, not at handover. Ownership you cannot exercise is a promise, not an asset.
- Write the next three priorities in business language, monthly. It keeps the roadmap yours.
- Ask for the runbook at the first milestone. It is the cheapest insurance in the arrangement.
- Read the exit clause before the pricing. It tells you more about the relationship than the rate does.
None of this requires you to become technical. It requires you to keep the four things that are actually yours, the accounts, the code, the decisions and the documentation, and let someone else carry the rest. If you are weighing whether to hand software off at all, the signs that software has become your bottleneck is the more useful starting point, and if you want a straight read on which parts to keep in-house, tell us how your systems are set up today.