Solutions

Staff Augmentation vs Dev House vs Fractional Team: Which One You Are Actually Buying

Three ways to buy engineering capacity, sold with overlapping words. The difference is who owns the roadmap, who manages the people, and what happens the month you no longer need them.

Ahmad Santarissy6 min read

The moment this decision gets made

It is rarely made calmly. A funding round closed and the milestones came with it. A lead engineer resigned. A launch date moved up. Somebody in the room says "we need more hands", and within a week there are three proposals on the table that all promise senior engineers, fast onboarding and flexible terms.

They are three different products. The words on the proposals overlap almost completely, which is why so many teams buy the wrong one and only find out three months in.

The fastest way to tell them apart is not the price or the stack. It is three questions. Who owns the roadmap? Who manages the people day to day? What happens the month you no longer need them?

Staff augmentation

Staff augmentation adds engineers to your team. They work in your repo, under your process, in your standups. You keep the roadmap, the code review and every decision. What you are buying is capacity and the removal of the hiring loop.

Who owns the roadmap: you. Who manages the people: you, the same way you manage your own engineers. The vendor handles fit, cover and replacement, and the engineer stays on the vendor's payroll.

The contract is usually a flat monthly fee per engineer, with a short minimum so the person can get up to speed and a notice period after that. At WeTheMakers that is three months, then month to month with 30 days notice, and a swap at no cost if the fit is wrong in the first two weeks.

Where it fails: when nobody on your side is actually managing. An augmented engineer with no lead, no backlog and no code review is an expensive way to write code nobody asked for. If you do not have a technical lead in the building, this is the wrong product, however good the engineer is.

The dev house

A dev house takes a project. You describe the outcome, they scope it, and a team you did not pick builds it somewhere you do not see, against a statement of work. What you are buying is a deliverable.

Who owns the roadmap: they do, inside the scope. Who manages the people: they do. You get a project manager and a demo cadence.

The traditional version of this model is the one I wrote about earlier this year: fixed scope, mixed-seniority team, slipping milestones, a handoff and a warranty. That version is collapsing because senior engineers with good AI tooling ship several times what they did in 2022, and a body shop selling headcount cannot compete with a small senior team selling output.

Where it fails: after the handoff. The knowledge leaves with the vendor. If the product is the company, a deliverable you cannot maintain is a liability with a launch party.

The fractional team

The third option has fewer names because it is newer. A fractional team is a small senior group, named engineers plus a lead, that owns an outcome for you on a retained basis without being your full-time staff. It is the shape a good dev house takes once it stops selling tickets.

Who owns the roadmap: shared. You own the why, the team owns the how, and scope gets renegotiated against the outcome rather than the original document. Who manages the people: the lead does, and the lead is accountable to you for the outcome, not for hours.

The contract is a monthly retainer against defined outcomes, with weekly demos. The team is still around after launch because they are the ones paged when it breaks, and that changes how carefully they build.

Where it fails: when the buyer wants a ticket list executed exactly as written. A senior team working against an outcome will kill features that do not serve it. If you need every line of a spec built, buy the dev house.

Side by side

Staff augmentationDev houseFractional team
What you buyCapacityA deliverableAn outcome
RoadmapYoursTheirs, inside scopeShared
Day-to-day managementYoursTheirsTheir lead, accountable to you
Contract shapeMonthly fee per engineerFixed-scope statement of workMonthly retainer against outcomes
When it ends30 days noticeAt handoffWhen the outcome is met, or on notice
Fails whenYou have no technical leadYou need to maintain what they builtYou want a spec built exactly as written

How to choose in one conversation

Start with the technical lead question. If you have one, and the constraint is hands, staff augmentation is the cheapest honest answer. Your lead keeps control and the vendor removes the three months a hire would take.

If you have no technical lead and no plan to hire one, do not buy augmentation. You will be managing engineers you cannot evaluate. A fractional team gives you the lead as part of the package. A fractional CTO plus augmentation gets you to the same place with more of the control on your side.

If the work is bounded, non-core and you will not need to touch it after launch, a dev house is fine. A marketing site, an internal tool, a one-off integration. The handoff problem only matters when the code is the business.

If the code is the business and you are not ready to build a full engineering team, that is what the fractional team is for.

What to ask before signing any of them

Ask for named engineers, not "we will assign someone". Ask who is on call when production breaks and whether that person is in the proposal. Ask what the notice period is and what happens to the code and the knowledge when it runs. Ask to see a weekly demo from a current engagement, not a case study.

A vendor who answers all four cleanly is selling one of the three models above and knows which one. A vendor who cannot is selling whichever one you seem to want, and that is the proposal to put down.

At WeTheMakers we sell two of the three. Staff augmentation when you have the lead and need the hands, and a senior outcome team when the product is the company. When the missing piece is the lead itself, that is a fractional CTO, and it pairs with either.