Somewhere between your second engineer and your twentieth, the thing that made your team good starts working against you. At two, everyone holds the whole system in their head and quality is a personality trait. At twenty, quality has to be a structure — and the road between the two is where product velocity, hiring standards and founder attention all fight for the same hours. The numbers are illustrative; the shape of the problem is not.
The scaling trap: velocity versus the bar
Post-Series A, the pressure is arithmetic. The roadmap assumes engineers you have not hired. Every open seat pushes you to lower the bar just slightly; every slightly-lowered hire makes the next lowering easier and the codebase worse. Meanwhile the founders who should be setting technical direction are spending their weeks in recruiting pipelines. Most scaling failures are not talent failures — they are this squeeze, resolved badly: either hiring fast and diluting the culture, or holding the bar and missing the market.
The hybrid shape
There is a third resolution: a small in-house core that owns the product and the architecture identity, extended by a dedicated external team that owns defined surface areas — real ownership of a bounded part of the system, not a ticket queue. The core stays small enough to hire slowly and well. The dedicated team gives you delivery capacity that arrives as a functioning unit with its own lead, instead of one recruiting cycle at a time. The division of labour is by surface, not by tier: the external team is not “the people who do the boring work”, it is the team that owns the billing platform, or the data pipeline, or the admin product, end to end.
What stays in-house, what extends well
Keep in-house, always: product judgement and direct customer contact. The people deciding what to build need to feel the customer’s problem first-hand, and that instinct does not survive being outsourced. Keep final architectural say in-house too — not every decision, but the identity of the system and the taste that shapes it.
What extends well is everything that rewards discipline more than proximity: platform and infrastructure work, delivery capacity on well-bounded product surfaces, QA rigour, the internal tools nobody in-house ever has time for. These are areas where a senior team with strong review habits outperforms a hurried in-house hire — and where handing over ownership does not hand over your product’s soul.
One culture, not two
The hybrid model lives or dies on a single question: is there one engineering culture or two? One culture means the external team works in the same repos, passes the same review gates, joins the same standups, and argues in the same channels as everyone else. The moment “their code” and “our code” become distinguishable phrases, you are running two organisations that share a git remote. This is the embedded model rather than the vendor model — we have written about how it differs from staff augmentation and classic outsourcing — and it is the reason the arrangement can feel like one team of twenty instead of ten plus a supplier.
The two failure modes
The first is throwing a spec over the wall. Write a document, hand it off, check back in a quarter — this fails with an external team for the same reason it fails with an internal one, only slower to surface. Surfaces are owned, but context is shared continuously: the external lead sits in your planning, hears the customer stories, pushes back on requirements like any senior engineer would.
The second is two-tier code review — external contributions reviewed with either suspicion or indifference. Suspicion tells the dedicated team they are contractors, and they will start behaving like contractors. Indifference lets a second-quality codebase grow inside your first one. Same bar, same gates, both directions: your engineers review theirs, theirs review yours.
Insourcing a surface back
A healthy hybrid org expects surfaces to move. As later rounds land and in-house hiring catches up, it can be right to bring a surface closest to the product core back inside — and that move should be an org-chart edit, not a rescue operation. It is cheap precisely when the engagement was exit-ready by design: the code already in your repos, running in your cloud, documented as part of the definition of done, so “insourcing” means reassigning ownership of something you already fully possess. This is how we structure engagements by default — named senior engineers on a fixed monthly team fee, a tech lead you interview before signing, production code inside the first month, and terms under which leaving, or partially leaving, is always cheap.
If you are staring at the gap between the team you have and the roadmap you promised, the team shapes we run are on the services page — and the first conversation is a technical call, not a sales call.