Buyers usually choose an engagement model by asking which one is cheapest or safest. Neither question has a general answer, because an engagement model is not a pricing mechanism. It is a risk allocation mechanism.

Every software project carries uncertainty about scope, effort and outcome. The model you choose decides who absorbs that uncertainty — you, us, or a defined split. Once you see it that way, the choice becomes much clearer, and the trade-offs stop being surprising halfway through delivery.

Here are the three common models, what each is genuinely good at, and how to tell which one fits.

Fixed scope, fixed price

You define what is to be built, we commit to a price and a date, and we carry the risk of it taking longer than expected.

Where it works well: projects with genuinely stable, well-understood requirements. A defined integration between two documented systems. A rebuild of something that already exists, where the target behaviour is unambiguous. Compliance work with a specified standard to meet. Anything where you can write down what “done” means and be confident that definition will not move.

What you are actually paying for: certainty. And certainty is priced. Because we carry the overrun risk, a responsible fixed price includes contingency for the things that might go wrong. If nothing goes wrong, you have paid for insurance you did not need — that is the deal, and it is a reasonable one when budget approval genuinely depends on a single fixed number.

The failure mode: fixed price applied to unstable requirements. Once the price is fixed, every change becomes a change request, and the relationship reorients around scope boundaries rather than outcomes. You start arguing about whether something was implied by clause 4.2 instead of about whether it is the right thing to build. Both sides behave rationally and the project still suffers.

A useful self-test: if you cannot write the acceptance criteria today, you cannot fix the price today. Run a discovery phase first and fix the price against its output.

Dedicated team

You retain a stable team — engineers, and typically QA and a technical lead — for a rolling period. You direct priorities; we supply, manage and retain the people.

Where it works well: ongoing product development where priorities evolve, where the roadmap is a direction rather than a specification, and where accumulated context has real value. If the same people will be more productive in month six than in month one because they understand your domain, this is the model that captures that.

What you are actually paying for: capacity and continuity. Risk sits with you — if a sprint delivers less than hoped, you still pay for the sprint. In exchange you get flexibility to change direction without renegotiating anything, and a team that gets better at your problem over time.

The failure mode: weak product ownership on your side. A dedicated team amplifies whatever direction it receives. Given a clear owner who can make decisions, it is the most effective model available. Given an absent or divided owner, it will produce a steady stream of output that does not add up to a product, and it will do so expensively.

Before choosing this model, name the person on your side who will make prioritisation calls and be available weekly. If you cannot, fix that first.

Staff augmentation

Individual engineers join your existing team, work inside your process, report through your management, and use your tooling.

Where it works well: when you already have a functioning engineering organisation and need more of a specific capability — a mobile specialist for two quarters, additional backend capacity to hit a deadline, a data engineer for a defined build-out. Your architecture, your standards, your code review.

What you are actually paying for: skills on demand, without recruitment lead time or permanent headcount. Nearly all delivery risk stays with you, because delivery is managed by your organisation.

The failure mode: using it as a substitute for engineering management you do not have. Augmented engineers integrated into a strong team perform like members of that team. Dropped into a team with no clear ownership, unclear standards or no onboarding, they will be slower than your own staff and you will conclude, wrongly, that the engineers were the problem.

Budget genuine onboarding time. An engineer joining an unfamiliar codebase needs ramp-up regardless of seniority, and pretending otherwise just moves the cost somewhere less visible.

Choosing between them

Three questions usually settle it.

How stable are the requirements?

Stable and specifiable today points to fixed scope. Evolving, or dependent on what you learn from users, points to a dedicated team. Fixed price on moving requirements is the single most reliable way to make a project adversarial.

Do you have engineering management capacity?

Strong internal engineering leadership makes staff augmentation efficient — you already have the machine, you are adding capacity. Limited internal engineering management points to a dedicated team or fixed scope, where the supplier brings delivery management with them.

Answer this honestly. Choosing augmentation because it looks cheaper per hour, when nobody internally has capacity to direct the work, reliably costs more overall.

How long is the horizon?

A defined piece of work with an end date suits fixed scope. Continuous product development over quarters suits a dedicated team. A temporary capability gap inside an existing roadmap suits augmentation.

Mixing models

These are not mutually exclusive, and the strongest arrangements often combine them deliberately:

• Fixed-price discovery, then dedicated team for build. The most common effective pattern. Buy certainty where it is achievable — the analysis — and flexibility where it is needed.
• Dedicated team with fixed-price carve-outs. Keep the core team on a rolling basis, and take well-defined, self-contained pieces as fixed price where the specification is genuinely tight.
• Augmentation now, dedicated team later. Start with individuals inside your team; as the scope of work grows, transition to a managed team with its own delivery lead.

What matters is that the choice is deliberate and revisited. Projects drift into the wrong model and stay there because changing it feels like an admission of error. It is not — it is a response to the fact that the project’s uncertainty profile changed, which is normal.

Getting the contract length right

Whichever model you pick, the commitment period is a separate decision and it is often made badly in both directions.

Commit too short and you pay for repeated ramp-up. Every new engineer needs time to become productive in an unfamiliar domain and codebase, and a three-month engagement can spend a meaningful fraction of itself on that. Rolling one-month arrangements feel flexible and quietly waste money on context that keeps being rebuilt.

Commit too long and you lose leverage. A twelve-month minimum with no exit provision means that if the relationship is not working by month three, you have nine months of paying to find out you were right.

The arrangement that works well in practice is a longer nominal term with a short notice period — enough continuity for the supplier to invest in staffing and for the team to accumulate context, and enough of an exit for you that both sides stay motivated. Somewhere around a month or two of notice on a rolling term suits most dedicated-team engagements.

Pair it with a genuine review point early on — a scheduled, honest conversation at the end of the first delivery increment about whether this is working — rather than waiting for renewal. Problems raised at month two are fixable; the same problems raised at month eleven are just a decision not to renew.

Questions to ask any supplier

1. Under this model, who absorbs the cost if the work takes 30% longer than estimated?
2. What exactly happens when we change our mind about a requirement?
3. Who manages delivery day to day, and who do we escalate to?
4. If we end the engagement, what do we own and how is handover conducted?
5. How is team continuity protected — what happens if a key engineer leaves?

The last two are the ones buyers most often forget and most often need. Get the answers in writing before signing, not after.

How we work

We operate all three models and will tell you which one fits your situation — including when that means a smaller engagement than you asked about. Our software development, web development and mobile app development teams are staffed to support any of the three.

Tell us about your project and we will recommend a model with the reasoning shown.