16 September 20257 min read
Ask a team what they would never outsource and you will get a long list delivered with some heat. Ask them why, item by item, and most of the list dissolves. What is left is usually three or four things, and at least one of them is something nobody mentioned.
The heat is worth understanding, because it is not really about the work. It is about the fear of not understanding your own product any more. That fear is correct. It is just aimed at the wrong target: the thing that protects you is not keeping a particular module internal, it is keeping the capacity to judge whether any of it is any good.
Decisions about what to build
The first genuine keeper is not code at all. Deciding what the product should do, for whom, and in what order is the work that cannot be delegated outward, because it is the accumulation of everything you have learned from your own customers and market. A provider can advise, and a good one will push back on a plan they think is wrong. They cannot own it.
This matters practically, not philosophically. Every outsourcing arrangement that drifts does so because product direction quietly moved to whoever was closest to the code. It happens gradually, through small decisions made in the absence of an answer, and by the time anyone notices, the roadmap belongs to the people who happened to be available at the moment each question arose. The fix is unglamorous: someone internal owns the backlog, and questions have an owner who answers within a day.
The parts of the system that compound
Some code is worth more the longer one person has lived with it. The pricing engine, the matching logic, the model, the core data structure that everything else is arranged around. Each decision in it depends on a hundred earlier decisions, most of which were never written down and some of which were wrong for reasons only a survivor of them can explain.
This is the classic keeper, and it is real. But be honest about its size. In most systems it is a minority of the code and a minority of the backlog. The rest of the repository is admin screens, integrations, reporting, migrations, tests, and the long tail of features that exist because a customer asked. Keeping the compounding core internal does not require keeping all of it internal, and conflating the two is how teams end up with senior engineers writing CSV exports.
The keys, and the accountability that comes with them
The third keeper is control of your own infrastructure and data. Not the operational work, which is outsourced constantly and successfully, but the ownership: the accounts, the domains, the production credentials, the cloud organisation, the ability to revoke access to any of it in an afternoon.
For a European buyer this is also a legal position rather than a preference. If personal data is involved you remain the controller, the data processing agreement describes what your provider may do with it, and no contract moves the regulator's attention off you. The same logic applies to IP assignment: work produced for you should be yours as it is produced, not assigned at the end of a project when the leverage has changed hands.
- Cloud and domain accounts in your company's name, with the provider added as a user
- Production secrets held by you, issued to the provider, revocable without their cooperation
- Source control owned by you, with the provider's people as members rather than owners
- A signed data processing agreement before any real data is touched, not after the first incident
- IP assignment written so it takes effect continuously, not on final payment
The ability to evaluate the work
The keeper that nobody names is technical judgement. Someone on your side has to be able to look at what came back and know whether it is good. Not review every line, which is neither realistic nor the point, but be able to tell a sound approach from a plausible-sounding one, and to notice when the answers to their questions have started getting vaguer.
Teams lose this by accident. They outsource a capability, the last internal person who understood it leaves, nobody replaces them because the work is covered, and two years later the company cannot assess its own systems. At that point you are not managing a provider, you are trusting one. It may work out. It is not a position you would choose deliberately.
Things that look like keepers and are not
Then there is the part of the list people defend loudest and lose most from keeping.
- Anything defended with the phrase it is too complicated to explain. If it cannot be explained, it also cannot be handed to a new employee, and you have a documentation problem rather than an outsourcing question.
- Work kept internal because it is sensitive, where sensitive means embarrassing rather than confidential. A neglected legacy system does not become less neglected by staying private.
- Support and operations, which are kept in-house on the grounds of customer intimacy far more often than the customer experience justifies, especially outside your own working hours.
- Quality assurance, frequently treated as a core function while being the thing least resourced internally, and often the single clearest early win for an outside team.
- The rewrite that everyone agrees is needed and nobody has time for, which is kept internal in principle and not done in practice for years.
The common thread is that these are defended by attachment rather than by analysis. A useful discipline is to require a reason that survives one follow-up question. Why must this stay internal? Because it is core. Why is it core? If the second answer is a restatement of the first, the item probably belongs on the other list.
How to run the sort on your own backlog
Take your current backlog and put each item in one of three buckets: it decides what the product is, it compounds inside the core, or it simply has to be done well. Do this with two people rather than one, because the disagreements are where the useful information is.
Then apply one test to the third bucket. Could someone who does not know your company's history tell whether the job was done correctly? If yes, the work has legible acceptance criteria and can leave the building, either as staff augmentation where you direct it or as managed delivery where the provider owns the outcome. If no, the work does not need to stay internal forever, but it does need a definition of done before it goes anywhere.
What you are protecting is not a list of files. It is the ability to decide, the knowledge that compounds, the keys, and one person who can tell you the truth about the work. Everything else is a scheduling question.