BYD TechThe short answer
Agree a fixed scope up front when the first version is small, well understood and unlikely to change, and accept that every change will go through a change request. Pay for time and materials, by the week or the sprint, when you expect to learn as you build and can set priorities often. Choose a dedicated team when there is a long roadmap and you want the same people to keep building, and only once there is enough work and someone on your side to direct it.
Key points
- The real difference is who carries the risk of the unknown: the team under a fixed scope, you under time and materials or a dedicated team.
- Fixed scope suits a well-understood first version with a clear edge. Every change becomes a change request.
- Time and materials suits a product you are still discovering, as long as you set priorities and watch the spend.
- A dedicated team suits a long roadmap. It needs a steady backlog and a decision-maker on your side, or capacity sits idle.
- Whatever the model, judge progress by working software you can try yourself, not by status reports.
- Many products move between models: scoping or a first version agreed up front, then time and materials or a dedicated team.
The three models in plain terms
Agencies and studios use different names for these, so judge the model by what is agreed, not by the label on the proposal.
- Fixed scope. You and the team agree up front what will be built, written down as features, screens or user stories. The team commits to delivering that list for an agreed amount. Anything outside the list is a change request, quoted and approved separately.
- Time and materials. You pay for the time the team spends, usually by the week or by the sprint. The list of work is a living backlog that you reorder as you learn. You can stop, speed up or change direction, and you carry the cost of whatever the work turns out to need.
- A dedicated team. A set group of people works only on your product, with no other client competing for their attention. It is time and materials at a larger, steadier scale: you are buying a team’s capacity, not a list of features, and you direct what it works on.
Underneath all three sits the same question. Software always contains things nobody knew at the start. Someone has to carry the cost of discovering them, and the model decides who.
Side by side
| Fixed scope | Time and materials | Dedicated team | |
|---|---|---|---|
| How scope change is handled | A written change request, priced and approved before work starts | Reorder the backlog; new work replaces or follows other work | Reorder the backlog; the team keeps going at the same size |
| Who carries the risk of the unknown | Mostly the team, which builds a margin into its estimate | Mostly you, through the time spent | You, through the team you keep on |
| How you see progress | Milestones against the agreed list | Working software at the end of each sprint | Working software and a roadmap you review with the team |
| What you manage on your side | Approving the scope, reviewing deliverables, deciding on change requests | Setting priorities often, reviewing each sprint, watching the spend | A product owner who keeps the backlog full and makes the calls |
| When it fits | A small, well-understood first version | A product still being shaped by what users do | An established product with a long roadmap |
| How it usually fails | Scope fights and software that matches the list but misses the need | Open-ended spend with no clear end | Idle capacity and a team nobody is directing |
Fixed scope: when the job is known
A fixed scope feels safe because the commitment is clear before work starts. It works when the job really is known: a contained first version, a defined integration, a rebuild of something that already exists and behaves as it should. It needs a written scope precise enough that both sides would agree on whether a given item is in or out; How to write a PRD and How to write user stories cover how to get there.
The risk does not disappear; it moves. The team carries the unknown, so a careful team builds a margin into its estimate and you pay for it whether the unknowns arrive or not. Martin Fowler calls fixed scope a mirage: some firms bid low and plan to make their profit on change requests, and a client who receives software that matches the list but does not deliver the value expected still bears the cost of the lost opportunity and the people’s time.
- Scope fights. Every unclear line in the scope becomes an argument about whether it was included.
- Change requests as a toll. Small, sensible changes wait for a quote and an approval, so people stop asking for them.
- Building to the letter. The team has every reason to deliver what was written, even after everyone has learned it is not quite what is needed.
- Cut corners late. When the estimate runs tight, testing and documentation are the easiest things to squeeze.
To make it work, keep the scope small, write down what is out of scope as clearly as what is in, agree how change requests are estimated before the first one arrives, and say what done means for each item.
Time and materials: when you will learn as you go
Most new products change once real users touch them. Time and materials accepts that. The Agile Manifesto values responding to change over following a plan, and the Scrum Guide describes the product backlog as an emergent, ordered list of what is needed to improve the product. Work happens in short, fixed-length cycles called sprints, and each ends with a review where the team shows what it built and the plan is adjusted.
Here you carry the unknown. If something turns out harder than expected, it takes more of the time you are buying. In exchange, a change costs nothing more than the time it takes, and you can stop when the product is good enough, rather than when a list is finished.
- Set a budget ceiling for each stage yourself, and decide in advance what you will do when you approach it.
- Name one person on your side who orders the backlog. The Scrum Guide makes the product owner accountable for maximizing the value of the product; if nobody does that job, the team decides by default.
- Go to every sprint review and try the software yourself. Time spent with nothing you can click is the warning sign.
- Ask to see the backlog and the plan at any time. The GOV.UK Service Manual recommends a backlog open to everyone and show and tells for people outside the team, so progress is visible without extra reports.
- Ask for an estimate of the remaining work at each review, with its assumptions, so the end stays in view.
The failure mode is open-ended spend: a project that is always nearly done, because nobody said what done looks like. Agreeing the one job the first version must do, as in How to build an MVP, is the best protection.
A dedicated team: when there is a long roadmap
A dedicated team makes sense once a product is live, has users, and has more worth building than a single project. The same people stay on it, learn the domain and the codebase, and stop paying the cost of getting up to speed again and again. It is the closest an outside team gets to an in-house one.
It asks the most of you. A team that works only on your product needs a steady supply of well-understood work and someone who can decide, quickly, what matters next. Without that, you pay for people waiting.
- Idle capacity. The backlog runs dry, or decisions wait for a founder who is busy selling, and the team fills its time with low-value work.
- The wrong size. A team sized for a big launch stays that size after the launch, when the work no longer needs it.
- Knowledge in the team, not the company. Over time the team becomes the only place the product’s history lives. Keep decisions written down and the code in your account, so you can change the team without losing the product; see Who owns the code.
- Drift. With no product owner, a capable team builds what interests it, which is not always what moves the business.
Before you commit, check that you can describe the next stretch of work in a roadmap, that someone on your side has the time to own it, and that the agreement lets you change the team’s size as the work changes.
How to choose, and when to switch
| Your situation | What usually fits | Watch out for |
|---|---|---|
| An idea that is not yet clear | A short scoping or discovery stage agreed up front | Committing to a full build before the problem is understood |
| A small first version you can describe precisely | Fixed scope | A scope with gaps that turn into change requests |
| A first version that will change once users try it | Time and materials with a ceiling you set | No one on your side ordering the backlog |
| A live product with more work than a single project | A dedicated team | Paying for capacity the backlog cannot fill |
| A project in trouble | A fixed-scope assessment first, then decide | Choosing a model before anyone has read the code |
Models are not a lifetime choice. A common path is to agree a scoping stage up front, build the first version on time and materials, and move to a dedicated team once the product has users and a roadmap. The GOV.UK Service Manual makes the same point about the first step: before you commit to building, understand the problem that needs to be solved.
If you are still choosing between agile and a plan-everything-first approach, Agile vs waterfall covers that decision. The model and the method go together: fixed scope sits naturally with a plan agreed up front, time and materials with sprints.
Questions to ask whichever model you pick
- What does your estimate assume, and what happens when an assumption turns out wrong?
- How is a change handled, and who decides whether it is in scope?
- How will I see working software, and how often can I try it myself?
- Who are the people on the team, and what happens if one of them leaves?
- Can we change the model, or the team’s size, partway through?
- Is the code in my company’s repository from the start, and when is the intellectual property assigned to me?
More questions to ask any team are in How to choose a software development company, and how to describe your project so the answers are comparable is in How to brief a software development agency.
BYD Tech prices by the project or by the week, never by the hour, with a ballpark on the intro call and a written estimate after scoping, and the code lives in the client’s GitHub from day one. MVP development explains how a first version starts.
Sources
Checked when this guide was written.
