Fixed price vs time and material comes down to one question: who carries the risk of the scope changing? In a fixed price project you agree scope, milestones and price up front, and the vendor carries the risk. In a time and material contract you pay for the hours actually worked and reprioritise every sprint, so you carry the risk but keep the flexibility. A dedicated team is a full-time team working only on your roadmap, suited to long-term product work. The right model depends on how settled your scope is and how long the work will last.
Most of the frustration people have with software vendors is not about the code. It is about a mismatch between the engagement model and the kind of work being done. A fixed price on a product that is still being discovered turns every new idea into a change request. Time and material on a small, well-understood job can feel like an open tab. Picking the right model up front avoids both.
This guide explains each of the software development engagement models, as we offer them at Upwwards, then puts them side by side and goes through which to choose when.
The models in one line each
We offer five ways to work together. The three in the title are the ones most people are choosing between. The other two solve narrower problems.
- Fixed-price project. Agreed scope, milestones and price up front. Best for a clear scope and a defined budget.
- Time and material. Pay for actual hours, reprioritise every sprint. Best for evolving products.
- Dedicated team. A full-time team working only on your roadmap. Best for long-term product work.
- Staff augmentation. Vetted engineers added to your in-house team. Best for filling skill gaps.
- Support retainer. Monthly hours for fixes, upgrades and features. Best for software that is already live.
Fixed price: certainty in exchange for flexibility
A fixed price software project starts with a written scope. Both sides agree what will be built, how it will be split into milestones, and what it will cost. You know the budget before work begins, and the vendor is responsible for delivering that scope for that price.
What it needs from you. A scope that is genuinely clear: the features, the user roles, the integrations, the data, and what "done" means for each milestone. The more of this is settled before signing, the better a fixed price works.
Where it goes wrong. Two places. First, the scope turns out to be less settled than everyone thought. Something learned in week three changes what should be built, and the change has to go through a change request, with its own estimate and approval. That process is fair, but it is slower than simply reprioritising. Second, because the vendor carries the risk of the unknown, a sensible fixed quote includes a buffer for it. You are paying for certainty, and certainty has a price.
Good fit. An internal tool with well-understood rules, a defined integration between two systems, a migration with a known data set, a first release where the scope has been deliberately kept small. A fixed price discovery phase is also a common way to start a larger project: it produces the written scope that makes everything after it easier to estimate.
Time and material: paying for the work actually done
In a time and material contract you pay for the hours the team actually works. Work is organised into sprints. We run two-week sprints with working demos, and at the start of each one you decide, with the team, what matters most next. If priorities shift because users said something unexpected, the plan shifts with them, without paperwork.
What it needs from you. Involvement. Someone on your side has to own the backlog, attend sprint reviews, and make decisions about what to build next. Time and material is flexible because you are steering. If nobody steers, it drifts.
How to keep it under control. Flexibility does not have to mean an open-ended budget. The controls that work are simple:
- A monthly or per-phase budget cap that the team plans against
- A prioritised backlog, so the most valuable work is always done first
- Sprint reviews where you see working software, not status reports
- Regular reporting of hours against the backlog
Good fit. An MVP, a product finding its market, any project where you expect to learn as you go. If you are building something new, our SaaS and product engineering work usually runs this way after an initial scoping phase.
Dedicated team: a team that is yours, without hiring one
A dedicated development team is a full-time team working only on your roadmap. It is not a project with an end date. It is closer to having your own engineering team, without recruiting, onboarding and managing each person yourself.
How it works with us. You tell us the roles, seniority and timeline you need. We share profiles of engineers who match, you meet them, and the ones you choose join your stand-ups, tools and sprint rhythm. If someone is not the right fit, we replace them. Roles cover full-stack, frontend, backend, mobile, AI and machine learning, DevOps, QA and UI/UX.
Why teams outperform rotating projects over time. The longer a team works on one product, the more it knows: why a rule exists, which part of the code is fragile, what the users actually do. That knowledge is expensive to rebuild every time a new vendor or a new project team starts. A stable team keeps it.
What it needs from you. A roadmap long enough to keep a team busy, and someone who sets direction. A dedicated team works best with a clear product owner, whether that is you or someone on your team.
Good fit. A product with a continuing roadmap, a platform your business runs on, or a company that needs engineering capacity for the long term but does not want to build a department from scratch.
Staff augmentation and support retainers
Staff augmentation is narrower. You already have a team and its leads, and you are missing a skill: a mobile engineer, a DevOps engineer, someone with AI experience. We add vetted engineers to your in-house team, and your leads direct their work.
A support retainer is for software that is already live. Monthly hours cover bug fixes, upgrades, security patches and small features, so the system stays healthy without a project being opened every time something needs attention. It is how our support and maintenance service runs.
Fixed price vs time and material vs dedicated team, side by side
| Fixed price | Time and material | Dedicated team | |
|---|---|---|---|
| Best for | Clear scope, defined budget | Evolving products | Long-term product work |
| How you pay | Agreed price by milestone | Actual hours worked | Monthly, for a full-time team |
| Who carries scope risk | Mostly the vendor | Mostly you | Mostly you |
| Budget predictability | High for the agreed scope | Moderate, managed with caps | High per month |
| Changing priorities | Through change requests | Every sprint | Continuously |
| Your involvement | Heavy at the start, lighter after | Steady, every sprint | Steady, as product owner |
| Typical length | A defined project | Weeks to months | Months to years |
| Main thing to watch | Scope that is less clear than it looks | Drift without a backlog owner | Not enough roadmap to keep a team busy |
Which to choose when
The table is the theory. In practice, the choice usually becomes obvious once you describe your situation honestly. A few hypothetical examples:
Say an operations team wants a booking tool to replace a shared spreadsheet. The rules are known, the users are known, and the integrations are limited. Choose a fixed price. The scope can be written down now, and a fixed budget makes approval easy.
Say a founder wants to test a new product with paying customers. The first release can be defined, but what comes after depends entirely on how users respond. Choose a fixed price or time and material for the first release, then time and material once real feedback starts arriving.
Say a business runs on a platform that needs new features every month for the foreseeable future. Choose a dedicated team. The work never really ends, and a team that already knows the system will move faster than a new one every quarter.
Say an in-house team is shipping a web product and now needs a mobile app. The team and its leadership already exist; what is missing is a skill. Choose staff augmentation.
Say the software is live, stable and mostly needs care. Choose a support retainer. Predictable monthly hours, without the overhead of opening new projects.
If you are still unsure, ask yourself two things. How much of the scope could you write down today and still agree with in three months? And how long will this software keep changing? Settled scope and short duration point to fixed price. Unsettled scope points to time and material. A long, continuing roadmap points to a dedicated team.
You can change models as the work changes
The engagement model is not a permanent decision. Products move through stages, and the model should follow them. A common path looks like this: a fixed price discovery or first release, time and material while the product learns from users, a dedicated team as the roadmap stabilises and grows, and a support retainer once the system is mature. We will recommend a model at the start, and you can switch as the work changes.
Whatever model you choose, a few terms are worth agreeing before you sign:
- How changes are handled. On a fixed price, how change requests are estimated and approved. On time and material, how the budget cap works.
- Who is on the team. Names and roles, and what happens if someone leaves or is not the right fit.
- What you own. With us, you own all of the code, IP and documentation at handover. Make sure any contract says so plainly.
- How you see progress. Working demos and reporting cadence, not just invoices.
- How to switch or wind down. Notice periods and handover steps, agreed while everyone is on good terms.
Finding the right fit
You do not need to have chosen a model before talking to a vendor. Describe the work, how settled it is and how long you expect it to keep changing, and the model usually follows. If you would like a recommendation for your project, book a free 30-minute discovery call. We will suggest the model that fits, with an approach, timeline and estimate, within two business days. For what drives the total itself, see what custom software development costs.
