In-house vs agency
Hire the team, or hire the build
Two vendors have told you opposite things, and both were describing their own business model rather than your project, so here is the part that actually decides it.
Ask us which one fitsWhy nobody gives you a straight answer
Both sides are describing their own shape. A recruiter is paid when you hire, an agency is paid when you sign a scope document, and each one sincerely believes the other is the risky option. Neither is lying; they are answering a question about their own business rather than about your product.
One question settles this more often than any other: after the first version ships, how often will someone need to change it? If the answer is every week for the next three years, you are hiring a team rather than buying a project; if it is rarely, and you will know what to change by then, buy the build.
Where it bites
Where the two genuinely diverge
Not a feature list. Each of these is a place where the choice shows up as a real decision, usually several months after you made it and forgot you had.
What you are actually buying
An agency sells a scoped outcome; a salary buys availability. Change the spec mid-build and one triggers a change order, the other simply absorbs it.
Time to the first commit
An assembled team can start within a week or two. A first hire is a search plus a notice period before anyone has written a line.
Where the knowledge lives
In-house context accumulates in people's heads and stays there until they resign. Agencies write it down because a handover is contractually due. Ask to see the runbook.
The risk you are swapping
Hiring means judging technical ability you cannot yet assess. An agency moves that risk to references and a paid discovery phase you are allowed to stop after.
Month nine, not month one
Apple and Google ship OS releases every year that break careless builds. Someone has to be there when yours breaks, long after the launch.
The shape of the spend
Salaries are a monthly floor whether or not there is work this sprint. Agency spend stops when the scope does. Neither is inherently cheaper.
Specialisms you need once
A smart contract audit, a PCI-DSS scoping decision, an App Store rejection appeal. Each needs someone who has done it before and then not again for a year.
The bad week
One in-house developer on leave stops the project. An agency swaps someone in, but the replacement re-reads your codebase on your clock and your budget.
Who checks the work
Neither model protects you from a lone developer's bad decisions. In-house that means a second senior hire; with an agency, an independent code review written into the contract.
The trade-offs
Four dimensions that decide it
Read the note, not just the verdict. Every one of these cuts both ways, and which way it cuts depends on something you can check about your own situation today.
- COST OF CHANGE
- In-house wins after the third change
- A change order carries overhead an agency has to charge for. Below a handful of changes that overhead is cheaper than a salary; past it, the paperwork starts costing more than the work itself.
- TIME TO LAUNCH
- Agency, by roughly one hiring cycle
- An assembled team starts in days. A first hire is a search plus a notice period before any code exists, which on a 12-week MVP is most of the schedule gone.
- WHO CAN MAINTAIN IT
- Whoever holds the deploy keys
- The question is not who wrote it but who can ship a fix on a Friday evening. Put the pipeline, the runbook and the credentials in the contract, not in the final invoice.
- WHAT BREAKS FIRST
- In-house, a resignation. Agency, the handover
- One engineer leaving takes the undocumented half of the system with them. The agency failure is quieter: a finished build that nobody still inside your company can confidently change.
Which one fits you
The common path is both, in that order: an agency builds the first version, and the first hire arrives once the product stops changing shape. Read these as a checklist you apply to yourself, not a description of the kind of company you want to be.
Choose an in-house team if…
- The software is the product, and it will change every week.
- You already have one senior engineer who can interview the next one.
- Your domain takes months to learn and lives in people's heads.
- You can fund salaries through a quiet quarter without cutting the team.
Choose a development agency if…
- You need a working first version before you know what to hire for.
- The build needs six specialisms you will not need again next year.
- Nobody on your side can technically assess a candidate yet.
- The work has a defined end, like a migration or an audited contract.
Frequently Asked
Questions
Common questions about hiring engineers, scoping an agency build, and moving the work in-house.
Per hour, almost always. Per outcome, often not, and most people run the wrong comparison: a salary is not the only cost of a hire. Add recruitment, equipment, management time, and the months where an engineer waits on a decision from you. The honest test is utilisation. If you can keep an engineer busy with work that genuinely matters for the next year, in-house wins on cost and keeps winning. If you cannot, you are paying a full-time rate for part-time work.
Yes, and it is the most common sensible path. The transition is only painful when nobody planned for it, so put the terms in the first contract rather than the last one: the repository lives in your organisation from day one, infrastructure is defined in code, and the handover includes a runbook plus a few weeks of paid overlap with your new hire. Agencies that resist those clauses are telling you something useful about how they intend to keep you.
Constrain the stack before the build starts, not after. Name the languages and frameworks your future hires will plausibly know, insist on a standard deployment pipeline rather than a bespoke one, and require a test suite a new engineer can run on their first day. Then ask for a session where one of your own people deploys a small change themselves, before the final payment. If that cannot happen, the handover has not really occurred, whatever the documentation says.
Neither, on its own. A single developer with nobody reviewing their work is the riskiest configuration in either model, because the first person to find the mistake is usually a customer. If you hire, budget for a part-time senior reviewer from outside. If you use an agency, check that a second engineer actually reads the code, rather than the one person you met on the sales call being the only one who ever touches it. The reviewer matters more than the employment contract.
You should own it outright, assigned in the contract rather than licensed to you. Check where the repository actually lives, because ownership on paper means little if the code sits in a vendor's private organisation and you have no admin access. The same applies to cloud accounts, domain registrations, app store listings and API keys. A useful test before you sign: if this agency disappeared tomorrow, could you still deploy? If the answer is no, fix that clause first.
Have a project in mind?
Fixed price after a paid discovery — no hourly billing. A real engineer reads every enquiry, and we reply within 24 hours.