Every founder eventually faces the question. Hire in-house, hire a freelancer, or bring in an embedded squad. The honest answer is "it depends" — but the variables are predictable, and most of the time you can read your own situation accurately if you know what to look for.
Here's how we'd tell you to think about it. We have a horse in this race, so take the bias into account. We've also told a number of founders that outsourcing was the wrong move for them, which is the part that makes the rest credible.
Outsource when the work is bounded and the stakes are real
The strongest case for an embedded squad is when there's a specific outcome you need delivered to a real deadline, the scope is defensible, and you can't hire fast enough to hit it. MVPs, enterprise-feature unblocks, platform migrations, security-audit prep. The kind of work that has a clear "done".
Squads are also the right move when you have an in-house team that's already at capacity, and adding another track would dilute the focus rather than add it. Lifting a defined chunk of work out of the team's queue costs less than reorganising the team to absorb it.
Outsource when you don't know what you don't know
If your first engineer is the first engineer you've ever worked with, you don't yet know what good looks like. A senior architect on retainer can be a forcing function for the boring parts — code review standards, deployment hygiene, the things in-house engineers absorb from a senior peer. You'll outgrow this need; for the first six months, it pays back fast.
Don't outsource your unique value
If the surface customers actually feel — the part that decides whether your product is a good product — is the part you're outsourcing, you have a problem. Not because external engineers can't build it well; they can. Because you'll never accumulate the muscle memory in-house to iterate on it. Outsource the load-bearing layer. Build the differentiated layer yourself, eventually.
Don't outsource when the brief is vague
An embedded squad with a fuzzy brief produces a lot of working software that misses the point. If you can't write a one-page scope that you'd defend in a board meeting, the next engagement should be Discovery — not Build. We've turned founders away from Build engagements for this reason. Better a refunded scoping week than a six-figure project nobody's happy with.
Don't outsource when the team morale story matters
Sometimes the answer to "hire or outsource" is "hire, slowly, and accept the cost". An external squad shipping the next product surface while your in-house team maintains the legacy one creates a two-tier dynamic that quietly poisons culture. If your in-house engineers will read "we hired them" as "they think we couldn't do it", that's information.
How to tell, before you sign
Three checks. Can you write the scope in a page? Can you name the moment success would be visible? Can your in-house team — or you, if there's no team yet — articulate why they'd want this engagement to exist? If all three are yes, an embedded squad is probably the right move. If any of them are no, slow down.
The discovery call is built for these conversations. Tell us where you are — including the parts that aren't tidy — and we'll tell you which direction we'd go. Honestly, even when the honest answer is "don't hire us".