“Dedicated development team”, “staff augmentation” and “project outsourcing” get used almost interchangeably in sales decks. That is convenient for vendors and expensive for buyers, because they are three different contracts with three different allocations of risk. Picking the wrong model costs more than picking the wrong vendor — so here is how we draw the lines, including where our own model is the wrong answer.
The three models, without the brochure
Staff augmentation
You rent individual engineers into your own team. You run the standups, own the architecture, review the code and carry the delivery risk. The vendor’s obligation ends at supplying a competent person who turns up. Augmentation works exactly as well as your own engineering management does — it adds hands, not judgement, and it adds nothing at all if nobody on your side has time to direct those hands.
Project outsourcing
You hand over a specification; software comes back. The vendor owns delivery and architecture inside the spec’s boundaries, and the contract is the interface: everything not written down is a change request. Done well, this is a clean way to buy a bounded artefact. Done against a moving target, it is a machine for generating disputes about what “done” meant.
Dedicated team
A standing squad — named engineers with a tech lead — that works only on your systems, in your repos, for as long as the engagement runs. You own product direction and priorities; the team owns engineering delivery; architectural decisions are made by people who expect to be maintaining the consequences next year. This is the model we sell, and it is not the right model for everyone.
When each model fits — including when ours doesn’t
- Choose augmentation — when you have strong engineering management and a temporary gap: one skill missing for a quarter, or a deadline that needs two more competent pairs of hands under your own tech lead.
- Choose project outsourcing — when the work is genuinely bounded: a migration, an integration, a well-specified build with a natural end, where the system will be handed to another team and the vendor’s context can safely be thrown away.
- Choose a dedicated team — when the system is long-lived and evolving — a product, a platform, a core internal system — and you want engineering capability that gets better at your problem every month instead of starting over every project.
And to be plain about the inverse: if your project is a few months of well-specified work with a frozen scope, do not buy a standing team from us or anyone else. You would be paying for continuity you will never collect on. Likewise if what you actually want is bodies under your own management — augmentation is the honest product for that, and we would rather say so on the first call than discover it in month two.
Three questions that pick the model for you
- How long will the system live? — The longer the lifespan, the more the compounding value of a team that already knows the codebase outweighs any difference in headline rates. Short-lived artefacts do not need standing teams.
- Where should context accumulate? — Every model accumulates context somewhere. Augmentation accumulates it in your employees’ heads. Outsourcing accumulates it in the vendor’s — and throws it away at handover. A dedicated team accumulates it in a squad that is contractually attached to you.
- Who owns the architecture? — If you have architects with capacity, augmentation lets them stay in charge. If scope is frozen and you never want to think about internals, outsourcing is defensible. If you want architecture owned by people accountable for operating it over years, that is what a dedicated team’s tech lead is for.
Why we only sell standing teams
Context compounds. An engineer in month twelve of your codebase is a different input from an engineer in week one — they know why the queue is shaped that way, which module bites, what the customer actually meant. Rotating people through resets that to zero, which is why our engagements are built the way they are: named squads at a fixed monthly team fee per named engineer, no blended rates. You interview the tech lead before signing, and nobody is swapped mid-engagement to a cheaper profile. Continuity is not an excuse for a slow start either — production code ships inside the first month.
We have run this shape end to end, at length: Lugmety, a full mobile app and web system for a major food delivery service in Saudi Arabia, was built and run by our squads from first commit to daily operations. That kind of system does not survive on throwaway context.
If you are weighing these models for a real system, our services page shows how a standing-team engagement is structured — and the first conversation about yours is a technical call, not a sales call.