In-house team or agency: the question isn't cost

The comparison almost everyone starts with is an agency day rate against a developer's salary divided by working days. The agency looks expensive, someone points out that you also pay for recruitment, equipment, benefits, management, and downtime, and the numbers move around until whoever is arguing hardest wins. It's a bad model, because cost is the least decisive variable in the decision.

The question that actually resolves it is simpler: how long does this work last, and how much of it will you still be doing in three years?

Work that ends versus work that doesn't

Some software work has a natural end. A migration, a first release, an integration with a partner, an ERP rollout. It needs a group of people at high intensity for a defined period and then it needs almost nobody. Hiring permanently for that shape of work leaves you managing a team you no longer have work for, which usually ends badly for everyone.

Other work never ends. If software is how your business makes money — the product itself, the pricing engine, the thing your customers log into every day — someone will be changing it every week for as long as the company exists. That work belongs in-house eventually, whatever it costs to get there.

• Fixed-duration, high-intensity, ends with a handover: strong case for an agency
• Continuous, business-critical, compounding domain knowledge: build the team
• Everything else: usually a mix, and the mix is the interesting part

The hiring lead time nobody prices in

A realistic timeline for a senior engineer, from opening the role to their first meaningful commit, is three to five months in most markets. If your build has to start now, in-house isn't actually one of the options available to you this quarter, regardless of which is cheaper over three years.

This is why the two paths so often run in parallel: an agency starts the work while you hire, with the explicit intention of handing it over. That only works if it's the plan from the start, which brings us to the part that decides whether it works at all.

Where domain knowledge accumulates

The strongest genuine argument for in-house isn't cost or control, it's that understanding of your business compounds in the heads of people who stay. An engineer who has been with you three years knows why the pricing logic has that exception in it, and will flag when a change breaks something nobody documented.

An agency can be told, and a good one will write it down, but it doesn't accumulate the same way. Where that knowledge is the actual competitive asset, that's a strong signal to build the team even when it's slower and more expensive to get started.

Honest failure modes on both sides

Agencies fail when the engagement is open-ended with no defined outcome, because nobody has an incentive to finish. They also fail when the client has nobody empowered to make decisions inside a day, which turns a four-month build into a seven-month one at no fault of the delivery team.

In-house teams fail when they're hired before there's a year of work for them, or hired without anyone senior enough to set technical direction. A team of three capable mid-level engineers with no architectural lead will produce something that works and is very expensive to change.

“Pick based on whether the work ends, not on which line item looks smaller this quarter.”

A reasonable default

1. 1Use an agency for the first release, a migration, or anything with a defined finish line
2. 2Hire in-house for the systems your customers touch every day and your margin depends on
3. 3If you're doing both, write the handover terms into the contract on day one
4. 4Hire your first senior engineer before your third mid-level one, not after
5. 5Revisit the split annually, because the shape of the work changes faster than the org chart

We do agency work, so read the above with that in mind. It's still the advice we give, including when it means telling a prospective client that what they need is a hire rather than us.