In-house vs outsourced development
Build the capability. Borrow the momentum.
The honest version of this decision is about the shape of your demand, not the quality of either option. Engineering demand that is steady and central to the product wants to be internal. Demand that arrives in bursts, or needs a skill you will use once, does not.
Start with the shape
of the problem.
The honest version of this decision is about the shape of your demand, not the quality of either option. Engineering demand that is steady and central to the product wants to be internal. Demand that arrives in bursts, or needs a skill you will use once, does not.
The mistake we see most often is hiring against a peak. A team sized for the busiest quarter is under-occupied for the other three, and the pressure to keep it busy generates work that nobody asked for.
| Criterion | In-house team | Outsourced partner | Edge |
|---|---|---|---|
| Business context | Deep and compounding. They know why the odd decision from 2023 was made. | Ramps in weeks and never fully matches an insider’s context. | In-house team |
| Cost structure | Fixed. Salary, benefits, tooling and management continue through quiet quarters. | Variable. Scales down without redundancy or morale cost. | Outsourced partner |
| Time to capability | Three to six months to hire, onboard and reach productivity. | One to three weeks, with people who have solved the problem before. | Outsourced partner |
| Specialist depth | Limited to what you can justify hiring for full time. | Accessible for the weeks you need it — accessibility, performance, migration, data. | Outsourced partner |
| Retention of knowledge | Stays with the company, provided people stay. | Leaves unless documentation and handover are contractual deliverables. | In-house team |
| Long-run cost at steady volume | Cheaper once utilisation is consistently high. | More expensive per hour if demand is genuinely constant. | In-house team |
- Software is the product and demand is constant
- Domain knowledge is your competitive advantage
- You can offer work interesting enough to retain senior people
- Utilisation will realistically stay above 80%
- Demand arrives in project-shaped bursts
- You need a specialism you will not use again for a year
- A deadline sits inside your hiring lead time
- You want the capability built and then handed over
Our honest
recommendation.
For most companies under a hundred people, the strongest model is a small internal team owning the domain and the roadmap, with an outside partner for surge capacity and specialist passes. The internal team keeps context; the partner absorbs volatility.
The version that fails is using an outside partner as a permanent substitute for ownership. Somebody inside your company has to own the architecture decisions, or you will be renting understanding of your own product indefinitely.
What teams ask next.
When nobody internally owns the technical direction. A partner can build well and still leave you with a product nobody inside the company can reason about, which is the expensive failure mode of this model.
Make documentation and a handover session contractual deliverables, keep code and infrastructure in your accounts, and have your engineers review pull requests even when they are not writing them.
Typically two to four internal engineers owning the roadmap and domain, with us running a defined workstream — a migration, an integration layer, an accessibility programme — alongside them and out again when it is done.
SaaS & custom software
Product engineering for the system your business runs on and no vendor sells off the shelf.
White-label development
Senior build capacity for agencies, under your brand, to your standard, on your timeline.
API & third-party integrations
CRMs, ERPs, payments and internal tools connected so the data stops being re-typed by people.
Rather not decide in the abstract?
Send us the situation. We will tell you which we would choose in your position, including when that answer earns us less.