What does a winning outsourcing business case contain?
A business case for outsourcing software development needs five things: a fully loaded cost baseline, a clearly stated delivery benefit, an honest risk section with mitigations, a phased commitment that limits downside, and the metrics you will be judged on afterwards. Papers that get rejected almost always fail on the first and third of those — they compare a salary with a day rate, and they present the arrangement as risk-free.
The audience matters. A CFO is asking whether the money buys more than it would elsewhere and whether the commitment can be unwound. A board is asking whether the company can execute the arrangement. Neither is asking for a vendor pitch, so keep vendor names out of the first version and argue the model instead.
How do you build a credible cost baseline?
Start with what your current capacity actually costs. Most internal estimates understate it, because salary is the only number that is easy to find. Build the baseline from the lines below and use the same rigour on the vendor side.
| Cost line | In-house engineer | Outsourced engineer |
|---|---|---|
| Direct compensation | Gross salary, bonus, pension | Included in the day rate |
| Employer costs | Social contributions, insurance, statutory benefits | Vendor's cost, already in the rate |
| Recruitment | Agency fee or internal recruiter time | Included; no fee on replacement |
| Vacancy cost | Months of lost capacity per hire | Weeks, and no cost during the gap |
| Workplace and tooling | Office, equipment, licences | Usually vendor-provided except your own SaaS seats |
| Attrition and replacement | Repeat recruitment plus ramp time | Contractual cover, but real ramp-up cost on your side |
| Management overhead | Line management time | Line management plus coordination time — usually higher |
| Irrecoverable VAT | None on salary | Real if you are partly exempt |
The last two lines are the ones a sharp CFO will test, so put them in yourself. The fully worked comparison, including how much management overhead to assume, is in our analysis of the true cost of ownership of in-house versus outsourced development teams. Add the second-order items from the hidden costs checklist so that nothing arrives as a surprise in month four.
Which benefits can you actually defend?
Cost per engineer is the weakest argument you can make, because it invites a debate about quality that you cannot settle on paper. The stronger arguments are about capacity, speed and optionality.
- Capacity you cannot otherwise buy. If your open senior roles have been unfilled for months, the comparison is not cheaper engineers versus expensive engineers. It is engineers versus no engineers, and the roadmap cost of the gap is quantifiable.
- Time to productive capacity. European senior hiring routinely takes three to six months including notice periods, while an offshore team can be productive in weeks. We set out why in time to hire in Europe versus offshore, and the delta translates directly into delivery dates.
- Flexibility. A contract with a notice period is easier to resize than a permanent headcount plan, in both directions. That is worth real money in an uncertain year, and boards understand it.
- Focus. Moving platform, integration, test automation and mobile work to a partner frees scarce internal seniors for the work only they can do.
Quantify one or two of these properly rather than listing all four vaguely. A single defensible number — "this brings the launch forward by one quarter, worth X in contracted revenue" — carries more weight than a page of benefits.
Which risks must the paper name?
Naming the risks is what makes the paper credible. Leaving them out invites the reader to supply their own, usually worse, version.
| Risk | Mitigation to state in the paper |
|---|---|
| Quality falls below internal standards | Same definition of done, code review by your engineers, agreed quality gates in the contract |
| Key knowledge leaves with the vendor | Your repositories, documentation as a delivery obligation, one internal owner per service |
| Data protection and security exposure | Processor agreement, standard contractual clauses where needed, no production personal data by default |
| Internal team morale and works council concerns | Early consultation, positioning as added capacity, no ambiguity about local roles |
| Vendor lock-in | Exit plan written at the start, notice period, transition assistance obligation |
| Management bandwidth | Named internal delivery owner with allocated time, not an extra duty for a busy lead |
What does a phased commitment look like?
Ask for a small decision now and a bigger one later. That is easier to approve, and it is genuinely better practice.
| Phase | Duration | Commitment | Decision gate |
|---|---|---|---|
| Paid pilot | 6–8 weeks | Two to three engineers, one real deliverable | Quality, communication and estimate accuracy against agreed criteria |
| Establish | 3–6 months | One full squad with an internal owner | Delivery predictability and internal team sentiment |
| Scale | 6–18 months | Additional squads as roadmap requires | Cost per delivered outcome, retention, incident rate |
The pilot is the part that turns opinions into evidence, and it is worth designing carefully — scope something with real ambiguity in it, not a screen you could specify to the last pixel. Our method is in how to run a paid pilot before committing to an outsourcing partner. Pair it with the right commercial model; the trade-offs between fixed price, time and materials and a dedicated team are covered in our guide to outsourcing contract models.
What do you commit to measuring afterwards?
Approval bodies remember the numbers you volunteered. Offer four or five you can actually produce:
- Delivered scope per quarter against the roadmap you would otherwise have had.
- Cycle time from ready to production, tracked before and after.
- Change failure rate and escaped defects, to close down the quality argument with data.
- Cost per delivered outcome, not cost per engineer.
- Retention of vendor engineers on your account, which predicts most future pain.
Report them at the same cadence you promised, including in the quarters where they are unflattering. That discipline is what converts a one-off approval into a durable arrangement.
What does the one-page summary look like?
Most approval bodies read one page carefully and skim the rest, so write that page last and make it self-contained. A structure that consistently works:
- The problem in numbers. Open roles, months unfilled, roadmap items slipping as a result. Two sentences, no adjectives.
- The proposal. What kind of team, doing which work, under which contract model, starting when.
- The money. Annualised cost of the proposed arrangement against the fully loaded cost of the internal alternative, with the assumptions named beneath.
- What you are asking approval for today. Ideally the pilot budget only, with the larger commitment held behind a decision gate.
- The three risks that matter and the specific mitigation for each.
- How it will be measured and when you will report back.
Two things to avoid on that page. Do not present a savings figure that depends on assumptions buried in an appendix — a CFO will find them and the whole paper loses credibility. And do not describe the arrangement as permanent; the strongest version of the case is that you are buying a reversible option on capacity, with a defined cost of exit that you have already thought about.
If the scope in your case is a product build rather than added capacity, ILMTEC delivers it end to end with senior engineers and AI-native tooling — see our AI application development solution for how those engagements are structured and priced.
