This is usually argued on principle and decided badly. Framed as a question about the shape of the work — how long, how specialised, how core — it becomes straightforward and the answer is often 'both, for different things'.
Duration is the first filter
Work continuing indefinitely favours employees; the knowledge compounds and the cost per month is lower. Work with an end — a migration, a launch, a fixed integration — favours a partner, because hiring for it means either a redundancy or an awkward search for a role afterwards.
Hire for what will still be here in two years. Contract for what will be finished.
Specialisation you need occasionally
A security review, an ML model, a performance investigation. You need the expertise a few weeks a year, so hiring means either paying for idle specialisation or hiring someone underqualified. This is the clearest case for external help and the one teams most often get wrong.
Speed is a real constraint
Hiring a good senior engineer commonly takes three to six months from opening a role to a productive start. If the opportunity is now, that timeline is the decision. Bridging with a partner while hiring properly is usually better than hiring quickly and regretting it.
The cost of a wrong hire is asymmetric
A poor agency engagement ends with notice. A poor hire in a five-person company affects morale, output and the founder's time for months. That asymmetry justifies more caution on hiring and more willingness to use partners while a market is still uncertain.
Keep the architecture decisions inside
Whichever route, someone in your company should understand the system well enough to evaluate proposals and say no. That can be a founder, a first engineer or a fractional CTO — but complete dependence on an external party for architectural judgement is the risk worth avoiding.
The common pattern
Most companies we work with end up with a small in-house core owning the product and its architecture, plus external capacity for surges, specialisms and defined projects. It is not a compromise; it matches the shape of how software work actually arrives.
