Short answer: build in-house when software is your core, long-term product and you have a steady roadmap that will keep a team busy for years. Outsource when the work has a defined scope or an uncertain future, when you need several skills for a few months, or when recruiting would delay the launch more than you can afford. Many companies do both in sequence: an outside team builds version one, then the company hires and takes over.
Where we stand. BBR is a studio that clients outsource to, so we benefit when readers choose outsourcing. We have tried to describe the in-house case accurately, including the situations where it is clearly the right answer.
The true cost of an in-house hire
Salary is the visible part. The rest is real money and real time, and it is easy to leave out of a comparison.
Recruiting
Writing the role, sourcing, screening, interviewing, negotiating and waiting out a notice period commonly takes a few months for an experienced engineer. During that time nothing is being built. If you use a recruiter, fees are typically a meaningful percentage of first-year salary. If you are not technical yourself, you also need someone to assess candidates, because a confident interview is not evidence of engineering ability.
Employment costs on top of salary
Employer taxes and social contributions, health insurance or equivalent, pension or retirement contributions, paid leave, equipment, software licences and, where relevant, office space. The size of this load varies a lot by country and by how generous the package is. It is never zero.
Management
Engineers need direction, code review, priorities and career development. If there is no technical lead, either a founder does this (taking time from sales, fundraising or product) or it does not happen and quality drifts without anyone noticing.
Idle time and skill mismatch
A product needs different skills at different moments: heavy design work early, backend work in the middle, mobile release work at the end. A permanent employee is paid through all of it, including the weeks when their specialty is not the bottleneck. Small teams feel this most, because one backend engineer cannot become a designer for three weeks.
Turnover
When an engineer leaves, you pay the recruiting cost again and lose whatever they knew that was not written down.
Illustrative arithmetic
The figures below are invented round numbers to show how the comparison is structured. They are not market data; substitute your own.
| Line | One in-house engineer, first 12 months after deciding to hire |
|---|---|
| Time to hire (assumed) | 3 months, no output, no salary yet |
| Salary for the remaining 9 months (assumed $120,000 a year) | $90,000 |
| Employer taxes, benefits, equipment, software (assumed 25%) | $22,500 |
| Recruiting (assumed fee or equivalent internal time) | $20,000 |
| Management time (assumed 4 hours a week of a lead or founder) | Not priced, but real |
| Cash cost over the 12 months | $132,500 |
| Productive months (9 employed, minus about 1 to ramp up) | About 8 of 12 |
With these assumptions, the first twelve months cost about $132,500 and deliver about eight months of output from one skill set, with the first of that output arriving in month four or five. A first product release typically needs design, backend and front-end or mobile work, which is two to four people or one project team. By contrast, a project quoted at, say, 20 person-weeks at a blended $60 an hour comes to $48,000 (20 × 40 × 60) and ends when the release ships.
The comparison reverses over time. In year two the recruiting cost is gone, ramp-up is done, and the employee's knowledge of your product compounds. If you have continuous work, the in-house engineer becomes the cheaper source of output, and the gap keeps widening.
Comparison at a glance
| Factor | In-house team | Outsourced team |
|---|---|---|
| Time to first working software | Months of hiring before the build starts | Weeks, including scoping |
| Cost structure | Fixed, ongoing | Variable, tied to a project or a monthly plan |
| Cost per unit of output, long term | Lower, if the team stays busy | Higher per hour; nothing to pay when there is no work |
| Breadth of skills | Whatever you have hired so far | Full set for the project's duration |
| Product and domain knowledge | Deep and cumulative | Good during the engagement; fades afterwards unless documented |
| Control over priorities | Immediate | Through the scope, change requests or a sprint plan |
| Management load on founders | High until there is a technical lead | Lower; product decisions and review |
| Scaling down | Painful, slow and costly | End of contract or reduced monthly plan |
| Culture and commitment | Strong when it works; equity aligns incentives | Professional rather than personal; aligned by contract and reputation |
| Main risk | Hiring the wrong person, or hiring before there is steady work | Picking the wrong vendor, or ending up dependent on one |
When in-house wins
- The software is the business. If the product is what customers pay for and you will improve it every week for years, the knowledge should live inside the company.
- The roadmap is steady. You can see at least a year of work that keeps the team occupied, and revenue or funding to pay for it.
- Deep domain IP. Proprietary algorithms, unusual data, or regulated processes where understanding takes months to build and is itself an asset.
- Fast, continuous experimentation. Products tuned through many small daily changes benefit from engineers who sit with product, support and sales.
- You already have technical leadership. A CTO or lead engineer who can hire well, review code and set direction removes the biggest in-house risk.
When outsourcing wins
- A first version with an uncertain future. Before demand is proven, fixed payroll is a bet on top of a bet. A project cost can be stopped.
- A defined project. A customer portal, an internal tool, a mobile app alongside an existing web product. The work has an end, and so should the cost.
- Several skills for a short time. Design, backend, mobile and release engineering for three months, none of them full-time for the whole period.
- No one to hire or manage engineers. A non-technical founder hiring a first engineer has little basis for assessing them. A studio with shipped work is easier to evaluate; see building without a technical co-founder.
- Software supports the business rather than being it. A logistics firm or a clinic needs good software, not a software department.
- A deadline that recruiting would miss.
Hybrid and transition models
Studio builds v1, you hire, studio hands over
This is the most common path for startups without a technical founder. It works when the handover is planned from the first day rather than negotiated at the end:
- Before the build: the contract assigns IP to you, and the repository, cloud account and store accounts are created under your company.
- During the build: a conventional, widely used stack, so that the people you later hire already know it. A short decision log and setup guide are maintained as the project goes on.
- After launch: the studio continues on a monthly plan while you recruit a lead engineer, with evidence from real users to show candidates.
- Overlap: the new hire works alongside the studio for a few weeks, takes over code review, then ownership.
- Taper: the studio drops to on-call support for a defined period, then exits or stays for specific projects.
In-house core, outsourced projects
Your team owns the main product and architecture. Outside teams take bounded pieces: the mobile app, an integration, a data migration, an admin rebuild. This keeps headcount stable while capacity flexes.
Staff augmentation
External engineers join your team, tools and rituals, managed by your lead. This is closer to in-house than to outsourcing: you get capacity, not management, so it only works if you already have technical leadership.
Ongoing product team without hiring
A studio acts as your engineering team on a monthly basis, with a fixed core of people and a shared roadmap. It suits companies that need continuous development but not yet a full department. BBR describes this model on the product engineering page.
A short decision procedure
- Is software the thing customers pay you for? If no, lean toward outsourcing and stop here.
- Is demand proven, with revenue or funding for at least a year of payroll? If no, outsource the first version.
- Do you have someone who can hire and lead engineers? If no, either find that person first or outsource while you look.
- Can you see twelve months of steady work for each role you plan to hire? If no, hire only the roles where you can and outsource the rest.
- If every answer was yes, build in-house, and consider outside help only for spikes and specialist work.
Protecting yourself in either model
- Employees and contractors alike should sign agreements that assign IP to the company. The details depend on jurisdiction, so use a local lawyer; this article is not legal advice.
- Keep credentials in a company-owned password manager, not in anyone's head.
- Require documentation as part of "done", whoever is writing the code.
- Avoid exotic technology choices that only one person or one vendor can maintain.
If you decide to outsource, the next questions are what kind of partner and how to contract with them. We cover those in agency vs freelancer and in the practical guide to outsourcing an app or SaaS build. If you decide to hire, how to hire developers for a startup covers order of hires and vetting.