Build, hire, or outsource? The CTO's guide to scaling engineering

TL;DR: Build vs. buy is not one decision — it's a sort. The first question is whether software is your product or your tool. The rule that follows: a scaleup's core system and IP should always be developed by the internal team; everything non-core — the boring screens, well-defined subsystems, new experiments — is a candidate for outsourcing. From a vendor who'll tell you when not to buy.

Somewhere on your desk is an approved engineering headcount plan. Before you open the first req, run one comparison nobody runs: what did last year's hires actually add to shipped output — and what would the same money have bought as outcomes?

I sell outsourcing for a living, and even I'll tell you: sometimes the answer is "hire the employees." Our longest client partnership ended exactly that way, and I'll argue below that the client was right. What follows is the sorting logic I walk founders through — including the parts that route work away from companies like mine.

The question before build vs. buy: is software your product, or your tool?

Most guides to software outsourcing skip straight to vendor selection, as if the decision to outsource were already made. Start earlier, with a question that changes every answer downstream: is software the thing you sell, or the thing that runs the thing you sell?

Rockpoint Legal Funding, our client of nine years, sells legal funding. Their platform — workflow, CRM, accounting — was mission-critical, but it was their tool, not their product. A company like that can healthily outsource the whole system's delivery for a decade, exactly as they did with us, because the software supports the moat rather than being the moat.

A SaaS scaleup is in the opposite position. The platform is the company. Its architecture, its velocity, its accumulated product judgment — that's the IP investors priced. The calculus for what you may safely hand to outsiders is completely different, and pretending the two situations are one is how generic outsourcing advice leads good CTOs into bad decisions.

Sorted? Then here's the rule.

The rule I give every scaleup: core stays in-house

The core system or IP of a scaleup should always be developed by the internal team. Always — that's my position as someone whose revenue would grow by convincing you otherwise.

The reasoning is ownership, not capability. An external team, however good, is structurally temporary; your core is structurally permanent. Every architectural judgment call in the heart of your product compounds for years, and the people making those calls should be people whose equity, roadmap, and Monday mornings live inside your company. When we work with SaaS scaleups, the healthy pattern is our people working around the core the internal team owns — never becoming the only ones who understand it.

The practical test for "core" is the moat test: if a competitor's engineers could read this code, would it teach them anything about why customers choose you? Your matching engine, your pricing logic, your data model's hard-won shape — yes. Your invoice PDF generator — no, and pretending otherwise is how internal teams end up spending their best quarters on work an external partner would deliver identically. Core is what differentiates, not everything the product team happens to touch.

Everything that is not core is a legitimate candidate for buying. And that boundary is bigger than most founders think, which is where the leverage hides.

When hiring employees is the right call

Two situations, honestly.

Extending the team that owns the core. If the work ahead is core-system and IP development, the capacity should be employees — see the rule above. Go in with the full cost stack visible, though, because the req's salary line is the smallest number involved. A senior developer in Germany averages around €75,000 gross, roughly €90,000 with employer contributions; tech recruiters charge 15–30% of first-year salary per placement before a line of code exists; and months pass before full productivity. I've published the complete comparison against external rates elsewhere, and here's the point: none of that changes the conclusion. Core work is precisely where the slow, expensive, permanent option is correct — you're not buying this quarter's velocity, you're buying years of compounding judgment. Budget it honestly and hire anyway.

Internalizing a stable system. Here's the story vendors don't tell. Our nine-year partnership with Rockpoint ended when their new management decided to internalize development. The system we handed over was stable, robust, and free of technical debt — and at that point, bringing it in-house was a completely valid option. They gained a same-timezone team and the possibility of meeting their developers in person more often; Mexico is, I'll admit, a bit closer to Los Angeles than Slovakia. When a platform matures from "being built" to "being evolved," the ownership argument that once favored an external delivery partner starts favoring employees. A partner who did the job well leaves you genuinely free to make that call — the handover cost them nothing, which is the whole point of doing partnerships properly.

What I'd push back on is hiring as a reflex — headcount as the default answer to "we're slow," before anyone asked whether the slowness lives in capacity at all. In Deloitte's 2024 Global Outsourcing Survey, 80% of executives planned to maintain or increase outsourcing investment while only 25% saw the cost or quality gains they bought it for — and the mirror image of that failure exists on the hiring side: teams grown to a size their leadership bandwidth and codebase quality can't convert into output. Both failures come from buying capacity before diagnosing the constraint.

What to outsource: the three best candidates

When a scaleup wants to stay a lean, flexible organization — rather than scaling the internal team and every complexity that comes with it — three categories of work are the natural things to hand out. Conveniently, they're also the three we've seen work over and over from the vendor side.

The non-core parts. Billing, account management, admin panels — all those boring screens. Every product is full of work that must exist and must work but will never differentiate you. Your best engineers resent it, your product velocity doesn't depend on who builds it, and it's usually well-enough understood to hand over cleanly. This is the least glamorous outsourcing and the most reliably successful.

Well-defined subsystems. A bounded component with clear edges and a testable definition of done. Previo is the archetype: a capable internal team owning their hotel-management core, while we designed and built the channel manager — a defined subsystem — from scratch. It now syncs 100,000+ daily updates across 10+ booking platforms with zero lost reservations, and Previo owns 100% of it. Their team never stopped owning the product; they bought one outcome their capacity couldn't reach.

New projects and experiments. The most underused category. Things outside your core business that might bring real value in the future — a spin-off product, a new market experiment, an internal tool — where the worst move is stretching your internal team thin across them. An experiment built by a partner arrives with its own delivery capacity, doesn't tax the roadmap, and if it succeeds you decide then whether it graduates into the core (and into internal hands). If it fails, your product team never lost a sprint to it.

Notice the pattern across all three: the closer work sits to your core, the stronger the case for employees; the more bounded and separable it is, the stronger the case for buying it. That single axis does more sorting than any vendor-comparison spreadsheet.

The mixes that work — and the one that fails

Real scaleups don't choose one model; they run a mix. The mix that works long-term looks like this: an internal team that owns the core and its architecture, a partner who owns delivery of defined subsystems or experiments, and — occasionally, temporarily — rented senior capacity filling a specific skill gap inside the well-led internal team. Each piece of work has one owner, and the ownership matches the work's distance from the core.

The mix that fails is using bought capacity as a substitute for ownership: external people attached to an overloaded core team, nobody owning the outcome, invoices honest and impact absent. I've watched that fail from the inside as one of ten rented teams, and it fails identically at every scale.

As Deloitte's survey puts it, "organizations today can leverage various alternatives to source talent, skills, and capabilities" — the alternatives aren't the hard part. Matching each piece of work to the right one is.

Running the sort on your actual roadmap

The framework only earns its keep applied, so here's the exercise — it takes an hour with your roadmap and your CFO's coffee.

List every initiative planned for the next two quarters. Label each one: core (touches the moat — the code that explains why customers choose you), bounded (clear edges, a testable definition of done, survivable if delivered by people who leave afterward), or experiment (outside the core business, valuable if it works, killable if it doesn't). Items that resist a label are usually two items stapled together — split them until every piece takes exactly one label.

Then look at the distribution against your capacity plan. If core work dominates and your internal team is thin, the headcount plan is right — open the reqs. If the list is heavy with bounded and experimental work, you're about to hire permanent employees for temporary shapes of work, and the same budget buys more as outcomes. And if half the roadmap is labeled core, be suspicious of the labeling before anything else: "everything is core" usually means nobody has asked the moat question honestly.

One warning before you trust the result. If the reason for the whole exercise is "we're slow," confirm the slowness actually lives in capacity. Often it lives in the codebase — coupling, debt, fragile deploys — and there, every kind of added capacity makes things worse at full price. That diagnosis is measurable: it's what a €5,000 audit establishes before you commit to any of the three moves.

FAQ

Should a startup outsource software development or hire in-house?

Sort by distance from the core. The product's core system and IP belong to internal employees — that judgment compounds for years and should live inside the company. Non-core work, bounded subsystems, and experiments are strong outsourcing candidates, especially if you want to stay lean instead of growing headcount and its complexities.

What should you never outsource?

Your core system and product IP — the thing that makes you defensible. This holds even when an external team is technically excellent: the issue is structural permanence and ownership, not skill. The exception is companies whose software is a tool supporting the business rather than the product itself; there, long-term external delivery of even critical systems can work well.

What parts of software development are best to outsource?

Three reliable categories: non-core functionality (billing, account management, admin screens), well-defined subsystems with clear boundaries and a testable outcome, and new projects or experiments outside the core business that shouldn't tax your product team's capacity.

Is outsourcing software development cheaper than hiring?

Per month, often comparable once you count the true employer cost of a senior hire — recruiting fees, ramp-up, severance risk. The real difference is in shape: outsourcing converts fixed headcount into a variable outcome, which matters most for bounded work and experiments. For permanent core work, the hiring costs are worth paying.

Can outsourcing work if we already have a strong engineering team?

That's when it works best. Previo's capable internal team kept full ownership of their product while buying one defined subsystem they lacked capacity to build — it now runs 100,000+ daily updates with zero lost reservations, and they own all of it. Strong teams buy outcomes; struggling teams buy rescue.

When should we bring outsourced development back in-house?

When the platform matures from being built to being evolved — stable, robust, low debt — internalizing becomes a valid option, with same-timezone and in-person advantages an external partner can't match. A healthy partnership makes that move cheap: documentation in place, knowledge already on your side, no lock-in.

How do we decide if our slowness is a capacity problem at all?

Diagnose before buying. Slowness often lives in the codebase — technical debt, coupling, fragile deploys — where added capacity of any kind makes things worse. An independent audit that maps how dangerous change is in your system costs €5,000 and tells you whether to hire, buy, or fix first.

Match the owner to the work

Build, hire, or outsource stops being a dilemma once you sort the work instead of debating the models: core to employees, bounded outcomes to a partner who owns delivery, gaps to rented seniors, experiments to anyone but your stretched product team. The mix is the strategy — and the discipline is keeping every piece of work with exactly one owner.

If you're mid-sort right now — headcount plan on the desk, roadmap not converging — book a 30-minute call. I'll tell you which pieces of your roadmap I'd take, which I'd refuse, and which need an employee's name on them instead of any vendor's.