Two founders sit down with the same software development agency in the same week. One signs a fixed-price contract for a six-month build, a clear brief, a fixed budget, a launch date circled on the calendar. The other signs a retainer, a set number of development days every month, no fixed end date, a roadmap that will keep changing. Eighteen months later, the first founder has shipped their product and is negotiating a brand new contract for every feature that follows. The second founder has quietly shipped a dozen updates, added an AI chatbot nobody had scoped at the start, and never had to renegotiate anything.
Neither approach is wrong. They are simply built for different roadmaps. This guide breaks down how retainer and project-based engagements actually work, what each costs a UK business in 2026, and how to work out which one fits where your product is right now, with practical examples and a straightforward decision framework.
Start your next software project
We’ll help you design, build, and ship reliable products on time.
Talk to our teamRetainer vs Project-Based: The Fundamentals
What Is a Project-Based Engagement?
A project-based engagement is a fixed-scope, fixed-price piece of work with a defined start and end. You agree the deliverables, the timeline and the budget upfront, the software development agency delivers against that brief, and the commercial relationship closes when the project does. It suits work with a clear destination: a new website, an MVP, a defined platform rebuild.
What Is a Retainer Engagement?
A retainer is an ongoing commercial relationship. You pay a fixed monthly fee for a set amount of development capacity, often expressed as days or hours, and the agency works through a rolling backlog of priorities rather than a single fixed brief. There is no natural end date. It suits work that keeps evolving: feature development, AI integration, ongoing maintenance, and anything where the roadmap six months from now is still being written.
Factor | Project-Based | Retainer |
|---|---|---|
Scope | Fixed and agreed upfront | Flexible, rolling backlog |
Budget | Fixed price or fixed estimate | Fixed monthly fee |
Timeline | Defined start and end date | Ongoing, no fixed end |
Best for | A single, well-defined deliverable | Continuous development and support |
Flexibility | Changes usually mean a new quote | Priorities can shift month to month |
Relationship | Resets with every new project | Builds context and speed over time |
Table 1: Retainer vs project-based, at a glance
What Does Each Model Actually Cost in the UK in 2026?
Cost is usually the first question, and the honest answer depends on which model you are comparing. The figures below reflect what UK businesses are typically paying in 2026 for custom software development, drawn from current market and agency pricing data.
Engagement type | Typical UK cost (2026) |
|---|---|
Project: simple tool or MVP | £15,000 to £80,000 (one-off) |
Project: mid-complexity platform | £80,000 to £180,000 (one-off) |
Project: enterprise system | £180,000 to £400,000+ (one-off) |
Retainer: light-touch (a few days a month) | £2,000 to £6,000 per month |
Retainer: dedicated developer | £6,000 to £12,000 per month |
Retainer: small dedicated team (2 to 3 people) | £12,000 to £30,000 per month |
Table 2: Indicative UK software development costs, 2026
Chart 1: What UK businesses typically pay for each model in 2026
A useful way to think about it: project-based pricing buys you a destination, retainer pricing buys you capacity. A £60,000 project and a £6,000-a-month retainer can represent a similar volume of development work over a year. The difference is how the risk, the flexibility and the commitment are structured.
Where Retainer and Project-Based Work Fit Your Roadmap
Most products do not stay in one place. They move through recognisable stages, and the engagement model that made sense at the start often stops making sense a year later.
Chart 2: Where each engagement model tends to fit a typical product roadmap
Early on, when you are validating an idea or shipping a first version, a project-based build gives you a fixed budget and a fixed date to hold the software development agency to. Once the product is live and priorities start shifting week to week, feature requests, an AI chatbot, a new integration, a retainer usually serves the roadmap better, because it removes the friction of re-scoping and re-quoting every time something new comes up.
Which Should You Choose? 5 Questions to Ask Yourself
1. Do you have a clearly defined scope and end date?
If you can describe the finished product on one page, with a natural point where the work is done, a project-based engagement gives you budget certainty. If the scope is still moving, forcing it into a fixed price usually just shifts the argument to change requests.
2. How unpredictable is your roadmap over the next six to twelve months?
A stable, well-understood roadmap suits a project. A roadmap that depends on user feedback, market response, or a system you have not built yet suits a retainer, since priorities can shift without a new contract every month.
3. What does your budget and cash flow actually look like?
Project-based work concentrates spend into milestones, which suits a lump sum for a defined outcome. A retainer spreads cost evenly, which suits businesses that prefer predictable monthly outgoings over a large upfront commitment.
4. Are you building something new, or evolving something that already exists?
New builds usually favour project pricing, since the deliverable is well understood even if the code is not. Ongoing evolution, feature additions, AI integration, performance tuning, almost always favours a retainer, because the work never really reaches a finish line.
5. Do you need specialist skills once, or on an ongoing basis?
A one-off need, such as a payment gateway integration or a data migration, fits neatly into a project. Recurring specialist needs, such as maintaining and retraining an AI model, are better served by a retainer that keeps the right skills engaged continuously.
Situation | Recommended model | Why |
|---|---|---|
First product, no existing users | Project-based | Fixed budget and date reduce risk while the idea is unproven |
Live product with a growing backlog | Retainer | Priorities shift too fast for repeated re-quoting |
One-off integration or migration | Project-based | Clearly scoped, single deliverable, natural end point |
Ongoing AI features or AI chatbots | Retainer | Models need monitoring, tuning and updates long after launch |
Table 3: Which engagement model fits your situation
