How to build a software team without hiring 20 people
By Steele Consulting
Every growing business eventually hits the same crossroads. The technical work has outgrown what one developer (or no developers, or one stretched-thin team) can do. The owner has to decide what to do about it — and the three options on the table look very different from each other.
Option A: hire more in-house staff. Build the team out.
Option B: outsource to a development firm. Pay for the deliverable, not the headcount.
Option C: build a hybrid — keep a small in-house team and embed an outside team alongside it.
All three are right for somebody. All three are wrong for somebody else. And the most expensive version of this decision is the one most owners make: pick the model that’s easiest to procure, not the one that fits the work.
In our 24 years at Steele Consulting standing up dedicated engineering teams for clients in every flavor of this situation, we’ve seen each model deliver beautifully and each model fail badly. The difference isn’t the model. The difference is whether the model matched the situation. This post is about how to make that match.
Why “just hire more people” is usually the wrong instinct
When the workload is bigger than the team, the default response is to hire. It feels safe, conventional, and within the owner’s control. It is also the most expensive way to solve most software capacity problems, for three reasons.
First, hiring takes time you don’t have. A senior developer in most markets is a 4-to-6-month hire-and-ramp cycle. The work you needed help with last quarter doesn’t wait that long.
Second, the people you actually want are not easy to find. Senior engineers with the right specialties have options. The ones available to you on demand are not, usually, the ones you should be hiring.
Third, hiring locks in fixed cost. The work you’re trying to absorb may be a six-month surge, a one-time platform rebuild, or genuinely permanent — and you don’t always know which when you start hiring. A salaried engineer is a 10-year decision dressed up as a 90-day one.
None of that means hiring is wrong. It means hiring is right under specific conditions and wrong under others. So is outsourcing. So is hybrid.
The three models, honestly
Option A: In-house
A team of W2 employees you hire, manage, and pay directly.
When it works: the work is steady, long-term, and core to your business. The team you’re building IS your product team — the codebase is the company. You’re in a talent market where the engineers you need actually live, and you can pay competitively. You have the management bandwidth to recruit, onboard, and grow the team.
When it fails: you need senior coverage you can’t attract. You need a capability quickly. The work has a defined endpoint. Your geography or budget doesn’t match the talent market. You’re hiring “an engineer” without knowing yet what kind.
Hidden cost: management overhead. A 10-person engineering team needs a director. A 20-person team needs an org. The payroll number is not the real number.
Option B: Pure outsourced
A development firm or vendor handles defined work. You scope the project, they execute, you receive the deliverable.
When it works: discrete builds with a clear endpoint — a new portal, a system migration, a one-time integration, a defined modernization. The vendor brings expertise and capacity for the duration of the project, then leaves. You walk away with the deliverable.
When it fails: ongoing capacity problems. Continuous product evolution. Work that has no clear endpoint. The classic anti-pattern: the business outsources a build, the firm finishes and leaves, and six months later the codebase is unmaintained and the company is back to square one with no team and a system they can’t extend.
Hidden cost: the cost of handoff. The day the vendor walks out, the institutional knowledge walks with them.
Option C: Hybrid / embedded
A small in-house team plus a dedicated outside team that works alongside them — same standups, same backlog, same code review process. The outside team brings senior coverage, specialized skills, or pure capacity, and stays as long as the work demands.
When it works: the work is going to keep coming, but you don’t need to triple your in-house headcount to do it. You need senior architecture coverage you can’t realistically attract. You need to absorb a surge without making permanent hires. You want the institutional knowledge to live with you, not with a vendor.
When it fails: the in-house team and the embedded team don’t actually integrate — different tools, different processes, different communication patterns. The result is two teams who don’t talk, doing related work, with the costs of both and the benefits of neither.
Hidden cost: the integration work itself. Hybrid only works when somebody does the hard work of making the two teams operate as one.
Three questions that decide for you
When clients ask us which model is right, three questions usually settle it within an hour.
Question 1: How long is the work going to last?
- Steady, long-term, core to the business → in-house has a real case.
- Defined endpoint, discrete scope → pure outsourced is probably right.
- Indefinite, evolving, can’t predict size 12 months out → hybrid is built for this.
Question 2: Can you actually attract the people you need?
Honest answer: in your market, at your budget, on your timeline.
- If yes → in-house works.
- If no → either pure outsourced (for discrete work) or hybrid (for ongoing).
Hiring people you can’t actually attract is not a plan. It’s a hope.
Question 3: What kind of help do you need — hands, specialists, or seniors?
- Hands (more capacity for work the existing team understands) → any model can work; choose based on Question 1.
- Specialists (one or two specific skills the team doesn’t have) → outsourced for a project, or hybrid if it’s ongoing.
- Seniors (architecture, technical leadership, mentoring the rest of the team) → almost always hybrid or in-house. Senior coverage is the hardest thing to source through a pure project-based vendor, because the vendor isn’t staying.
Run these three questions honestly and the answer is usually obvious. The mistake we see most often is owners who answer Question 2 the way they wish the answer was, not the way it actually is.
How this connects to the other decisions you’re making
This decision rarely lives alone. The owner asking “in-house, outsourced, or hybrid” is usually also asking what we covered in The Real Cost of an Underbuilt Tech Team — they’re trying to fix a structural mismatch between what the business needs and what the team can deliver. And they’re often asking some version of the question we covered in What to Look for in a Software Partner When You’re Not Technical Yourself — because whichever model they pick, they have to evaluate the people on the other side.
Read together, those three pieces form most of the answer. This post is the model choice. The underbuilt-team post is the diagnosis. The software-partner post is the vendor selection. The mistakes we see in the field almost always come from skipping one of the three.
Common patterns that fail
A few patterns are worth flagging directly, because they show up over and over:
- Hiring “an engineer” without knowing what specialty you actually need. You’ll end up with the wrong shape of help, hired in a way that’s hard to undo.
- Outsourcing the entire build, then trying to bring it in-house two years later. The handoff is almost always more expensive than the original build.
- “Hybrid” that’s really just two separate teams. If they don’t share standups, code review, and tools, it’s not hybrid — it’s expensive parallel work.
- Hiring a single senior engineer to fix a coverage problem. The bus risk you were trying to solve just got worse.
- Using a vendor for ongoing work that has no endpoint. The vendor’s incentives diverge from yours the moment the project becomes indefinite.
How we approach this at Steele Consulting
Our Virtual Teams practice exists specifically for the hybrid case — businesses where the work is going to keep coming, the talent market won’t deliver the senior coverage in-house, and the owner doesn’t want to triple their engineering payroll to solve a capacity problem. We embed senior engineers, architects, and full-stack developers into the client’s existing operation, with explicit handoff protocols so nothing concentrates around any single person.
We will also tell you, in the first conversation, when hybrid is the wrong model for your situation. If your work has a defined endpoint, you should hire a vendor for the project. If you’re a product company in a strong talent market with steady long-term work, you should hire in-house. The right answer for your business is the right answer — not the one that’s most convenient for us.
If you’re sitting in the middle of this decision and want a second set of eyes on it, that’s the conversation we’re built for. Reach out and we’ll walk through the three questions with you.