Hiring Engineers vs. Buying Engineering — The Decision Nobody Makes Deliberately

Most engineering team decisions happen before anyone calls them decisions.

Someone leaves. You open a headcount req. A deadline is six weeks out. You bring in a contractor. A feature needs building and the team is underwater. You find an agency. Each of these feels like a response to an event, not a choice about how to build software. That's the problem.

The question isn't "hire or outsource." That framing assumes the decision is about cost or speed. It isn't. It's about capability: what do you need to own permanently, and what do you need to execute well once?

When you get that wrong — in either direction — the cost shows up later, usually when you can least afford it.

When hiring is the right call

Hiring makes sense when knowledge compounds. When the thing being built is the core product and the feedback loop between what you learn and what you build needs to stay short, external capacity adds friction that doesn't show up in the contract but does show up in the codebase.

A product team iterating on its core recommendation engine every two weeks needs engineers who hold the context of every previous decision. You cannot hand that off. The institutional knowledge is the edge, and it lives in people.

Hiring also wins when your engineering surface is predictable and growing. If you know you'll have three new features per quarter for the next two years, the unit economics of a full-time team beat a contract model on almost every dimension that matters.

When buying wins

Defined scope. Time-constrained. No ongoing maintenance burden. That's the profile that points toward external capacity.

The failure mode here is the seniority illusion: bringing in one strong generalist to do work that needs a team. A startup hires an excellent engineer to rebuild their payment infrastructure in three months. The engineer is excellent. The timeline is not. What they needed was four people for six weeks. They ended up with one person for six months, and the project landed late anyway.

Buying also wins when the work is adjacent to the core product, not central to it. A data pipeline. A mobile app that mirrors your web product. An integration your core team doesn't have time to build and won't maintain daily. These are execution problems, not capability problems. Hire for capability. Buy for execution.

The failure mode nobody admits

Companies default to hiring because it feels more controllable. You're paying salary; they're on your team; they answer to your process. The logic holds until you run the numbers.

A wrong hire costs twelve to eighteen months. The time to recruit, the ramp period, the time before you know it's wrong, and the time to exit. None of that is recoverable. A wrong contract is expensive and finite — the scope closes, the engagement ends, and you know within weeks whether you got what you paid for.

The asymmetry runs the other way too. A great hire compounds over years. Their knowledge of your system makes every subsequent decision better. A great contractor delivers the scope and leaves. The knowledge leaves with them unless you've built for the handoff.

Neither is inherently better. The point is that these are different risk profiles, and most companies treat them as interchangeable.

Three questions worth asking before the next decision

Not as a checklist — these need to be worked through, not ticked off.

First: is this work you need to understand permanently, or execute well once? If you can't answer that cleanly, the scope isn't defined enough to make a good decision either way.

Second: what does the feedback loop look like? If the work requires close iteration with product, design, or customer input, external capacity adds friction that slows you down. If the spec is stable and the output is verifiable, that friction is manageable.

Third: who handles it when it breaks at 2am? If the answer is "someone on your team" — regardless of who built it — you need continuity of understanding. That points toward internal capability, not external delivery.

The decision almost always feels obvious in the moment. Someone left, a deadline is coming, a feature needs to ship. Reacting to those events isn't wrong. But the organisations that build strong engineering capacity are the ones that notice when they're making structural decisions inside tactical urgency — and slow down long enough to ask whether they're solving the right problem.