HOME/ENGAGEMENT MODELS

Engagement Models

Pick the engagement model that fits the work, not the one that suits the vendor

Fixed-scope projects, staff augmentation and dedicated teams each solve a different problem, and each is a poor fit for the other two. This page explains where the line falls so you can choose before anyone writes a proposal.

Book a free consultation See our work

A senior engineer replies within 24 hours — not a sales rep.

Where the choice usually goes wrong

You are being sold a model rather than matched to one

Every firm has a shape it prefers to sell, and the recommendation arrives before anyone has asked how settled your requirements are. The result is an arrangement built around the supplier's comfort, and a client who spends the next year working around a contract that never described their situation.

Fixed price feels safe right up until the requirements move

You wanted certainty, so you bought a defined scope for a defined price. Then week six brings a genuine insight about your users and the honest response is to change direction. Instead there is a change-request conversation, an estimate for something that would take two days, and a slow erosion of goodwill on both sides.

Flexible arrangements make next quarter unforecastable

Hourly billing adapts to whatever the work turns out to be, which is exactly why finance cannot plan around it. The invoice reflects how busy a month happened to be, and the conversation about next year's engineering budget starts with an apology instead of a number.

The model outlives the reason you chose it

The shape that suited a first build — tight scope, defined end, one push to launch — is usually wrong twelve months later when the product is live and priorities move weekly. Very few teams revisit the arrangement. They just keep renewing something that stopped fitting a while ago.

Four questions that settle it

Choosing well is not complicated, but it does depend on answering a few things honestly before price enters the conversation. These are the questions we work through on a first call, and they occasionally point away from the larger engagement.

How settled is the scope, really?

Fixed-scope only works when requirements can be written down and will survive contact with reality. A regulatory integration, a defined migration, a well-understood internal tool — those are fixed-scope shaped. A first product for a market you are still learning is not, and pinning it down early buys certainty about the wrong thing.

Who is going to own delivery?

This is the fork between augmentation and a dedicated team. If you have a tech lead with the capacity and appetite to run more people, augmented engineers slot into their team and you keep accountability. If nobody internally can take that on, you need a unit with its own lead — otherwise you have bought capacity that quietly manages itself.

Does the work have an end?

Some work finishes. Some work is a product that will still be changing in three years. Project-shaped arrangements are efficient for the first and wasteful for the second, because you repeatedly pay for a new team to learn what the previous one already knew. Continuity is worth money precisely when the domain is intricate.

What does leaving look like?

The best time to think about handover is before you start. Whichever model you choose, the code, documentation and pipeline should be yours throughout, and moving the work in-house or elsewhere should be a normal transition rather than an extraction. We would rather agree what that looks like at the beginning than discover the assumptions differ later.

What this covers

Pick the piece you need, or bring us the problem and we'll tell you which applies.

Staff Augmentation

Individual engineers join your existing team, take tickets from your backlog and report to your tech lead. Choose this when you have a functioning engineering organisation with a capacity gap — and avoid it when you have no internal lead, because augmented engineers need direction from someone who owns the outcome.

Best fit: a known roadmap, an internal lead with time, and a specific skills or headcount shortfall
Wrong fit: no one internally to set priorities, or a workstream that needs QA and planning as well as code
You keep accountability for delivery, architecture decisions and the definition of done
Read the full staff augmentation page for vetting, onboarding and how engineers integrate with your process

Dedicated Development Teams

A standing group — engineers, QA and a named tech lead — that owns a product or workstream and answers to you for what ships. Choose this when the work has no natural end and nobody internal can run it; avoid it when the scope is genuinely finite, since you would be buying continuity you do not need.

Best fit: an evolving product, shifting priorities, and no internal lead with spare capacity
Wrong fit: a defined one-off build with a clear finish line, where a scoped project is cheaper and simpler
Accountability sits with our tech lead, who runs the sprint and tells you when a date is at risk
See the dedicated development teams page for team composition, ownership boundaries and reporting

The stack we build on

Chosen to fit the problem — not because it's what we used last time.

Product and web engineering

TypeScript
React
Next.js
Node.js
Python
Java
Laravel

Mobile and cross-platform

Swift
Kotlin
React Native
Flutter
Firebase

Cloud, data and delivery

AWS
Azure
PostgreSQL
MongoDB
Docker
Kubernetes
Terraform

Quality and visibility

Playwright
Cypress
Jest
GitHub Actions
Jira
Grafana

How we'll work together

Every stage ends with something in your hands — not a status update.

01
Describe the work, not the contract
The first conversation is about what you are trying to build, who is available on your side, and how confident you are that the requirements will hold. We deliberately avoid discussing commercial shape until that picture exists, because the shape follows from it.
You get: A written summary of the work, the constraints and the internal capacity we understood you to have.
02
Stress-test how stable the scope is
We take the two or three areas most likely to change and talk through what happens if they do. If a plausible change would break a fixed scope, that tells you something useful before it costs anything, and it usually reframes the decision entirely.
You get: A short risk note listing which parts of the scope are firm and which are still assumptions.
03
Recommend a model in writing, with the trade-offs
You get a recommendation that names what you give up as well as what you gain, including cases where a smaller arrangement serves you better than the one we would prefer to sell. Where a hybrid genuinely fits — a scoped first build followed by ongoing ownership — we say so.
You get: A proposal setting out the recommended model, the alternatives considered, and why they were set aside.
04
Revisit the fit as the work changes
Engagements drift out of shape as products mature. We review the arrangement at sensible intervals with your stakeholders and raise it when the model no longer matches the work, including when that means a smaller engagement than the current one.
You get: A periodic engagement review covering what shipped, what changed, and whether the current model still fits.

Where we've applied this

Healthcare

Compliance-bound work often has genuinely fixed requirements, so a scoped project fits; the clinical platform it plugs into usually needs a standing team that remembers why each rule exists.

Logistics

A single carrier integration is a defined piece of work. A routing and tracking platform that gains a new partner every quarter is continuous ownership, and treating it as a series of projects is expensive.

Retail and e-commerce

Seasonal peaks argue for augmenting an existing team when volume rises, rather than carrying capacity you do not need in February.

Finance

Regulatory deadlines suit scoped delivery with a hard date, while lending or payment products under continuous change are better served by a team that stays with the codebase.

Manufacturing

Shop-floor tooling and ERP integrations tend to start as a scoped build and become ongoing work once operations depend on them daily.

Education

Academic calendars concentrate the work, so many institutions run a small standing team and add engineers ahead of enrolment rather than staffing for the peak year-round.

Clients we've built for

Real products, in production, with real users on them.

National Industries Company

Mobile Travelers

Prime Selection

Science and Mind

Questions buyers ask us

Which model is cheapest?

None of them, universally — which is why the question is worth reframing. Fixed-scope carries a risk premium, because someone has to price the unknowns and that someone is not going to guess low. Capacity-based models remove the premium but shift the risk to you: if priorities are unclear, you pay for people while the direction is being worked out. The real cost driver in every model is rework caused by building the wrong thing, and that is a function of how well the problem is understood, not of the contract type.

When is fixed-scope genuinely the wrong choice?

When you cannot describe the finished thing precisely enough for someone else to build it without asking. Discovery work, first products in an unproven market, and anything where user feedback should legitimately change the plan all fit badly. The tell is a specification full of phrases like "similar to" and "as appropriate" — those are unresolved decisions, and a fixed price simply moves the argument to later.

Can we start with one model and move to another?

That is a common path and often the right one. A scoped first build gets a product live with a defined budget, then ongoing ownership takes over once the roadmap starts responding to real users. It also runs the other way: teams sometimes reduce a standing team to a couple of augmented engineers when a product settles into maintenance. We would rather change the arrangement than watch you renew one that has stopped fitting.

How do you decide what to charge under each model?

Scoped work is priced against a specification we have both agreed, after enough discovery to be confident in it. Capacity-based work is priced on the size and seniority of the people involved. Beyond that we will not put numbers on a web page, because the drivers — stack scarcity, timezone coverage, QA and DevOps needs — vary too much to make a published figure meaningful. Describe the work and we will put a specific proposal in writing.

Who owns the code and the IP?

You do, in full, from the first commit, under every model. That includes the repository, the documentation, the deployment pipeline and any infrastructure configuration. Nothing in how we work is designed to make leaving difficult, and if you take the work in-house we would rather hand it over cleanly than have it remembered as an awkward exit.

What happens once the work is live?

That is often where the model needs revisiting. Software people use keeps changing, so a project that ends at launch leaves you with a codebase and nobody who knows it. Some clients keep a small ongoing arrangement for monitoring, fixes and iteration; others take it in-house with a handover period and documentation. Both are fine, and it is worth deciding which before launch rather than in the week after it.

Not sure which model fits your situation

Describe the work, who you have internally and how firm the requirements are. A senior engineer replies within 24 hours with a recommendation and the reasoning — including when the answer is a smaller engagement than you were expecting.

Book a free consultation Browse all services