Quick answer
Fixed price suits small, well-understood software jobs where you can write down exactly what is needed; our web applications start from £1,999. Agile, paid in short rounds of work, suits projects where needs will change as you learn. Most small businesses do best with a mix: a fixed first version, then agile improvements.
When you commission software, whether a booking system, a customer portal or an internal tool, the developer will usually offer one of two ways to work: a fixed price for a fixed scope, or an agile arrangement where you pay for time in short cycles and the plan adapts as you go. This guide explains both in plain English, where each goes wrong, and how a small business can get the benefits of both without an open-ended bill.
The two models in plain English
Fixed scope, fixed price means you agree what will be built, in writing, before work starts. The developer quotes one price for that scope. If you want something extra later, it is a change request with its own price. You know the cost up front; the trade-off is that the plan is hard to change.
Agile means the work is done in short cycles, often called sprints, usually one or two weeks long. At the end of each cycle you see working software, give feedback and decide together what to build next. You pay for the time used. The Manifesto for Agile Software Development sums up the thinking, valuing “working software over comprehensive documentation” and “responding to change over following a plan”. You get flexibility; the trade-off is that the final cost is less certain.
Side by side
| Fixed scope, fixed price | Agile | |
|---|---|---|
| Cost certainty | High, if the scope holds | Lower; controlled by a budget cap per cycle |
| Flexibility | Low; changes cost extra | High; priorities can change each cycle |
| Upfront work | Detailed specification before any build | Short planning, then learn by building |
| When you see software | Often near the end | Every week or two |
| Your time needed | Heavy at the start and at sign-off | Steady: reviews every cycle |
| Main risk to you | Getting exactly what you specified, not what you needed | Spending more than planned without a clear finish |
| Best for | Small, clear, well-understood jobs | New ideas, unclear needs, ongoing products |
Where fixed price works well
Fixed price is the natural choice when you can describe the job completely before it starts. That is more common in small business software than people assume:
- A booking form that writes to a calendar and sends confirmations.
- A simple client portal where customers log in to see documents and invoices.
- Connecting two systems you already use, so data stops being typed in twice.
- Replacing a well-understood spreadsheet process with a small web app.
If you already run the process by hand and know every step, you can write the specification. A fixed price then gives you what small businesses value most: a number you can budget for.
Where fixed price goes wrong
Fixed price breaks down when the specification is guesswork. Three things tend to happen.
- The quote is padded. A developer pricing an unclear job has to cover the risk, so you pay for uncertainty whether it happens or not.
- Change requests pile up. As soon as you see the software, you realise what you actually need. Every change becomes a negotiation and a new invoice.
- You get what you asked for, not what you needed. The developer builds the specification faithfully, and it turns out the specification was wrong. Nobody is at fault, but the money is spent.
The fix is not to abandon fixed price but to make the scope genuinely knowable before you fix it, which is what discovery is for.
Where agile works well, and where it goes wrong
Agile shines when nobody can honestly write the full specification up front: a new product, a tool for a process you have never run, or software that will keep growing for years. Seeing working software every week or two means mistakes are caught early and cheaply.
For a small business, the risk is open-ended spending. Without a firm budget and a clear definition of what “done” looks like, agile can drift: each cycle adds something useful, and the bill keeps growing. The GOV.UK Service Manual’s guide to agile delivery, written for government teams, still organises agile work into phases (discovery, alpha, beta and live) precisely so there are decision points along the way. A small business needs the same discipline on a smaller scale.
The hybrid most small businesses should use
In practice, the best arrangement for a small business usually combines both models in three stages.
- A short discovery. Map the process, the users and the must-haves before anything is built. The GOV.UK guide to how the discovery phase works stresses learning about the problem first and not starting to build during discovery. For a small project this might take days, not weeks.
- A fixed-price first version. With the must-haves clear, the developer can quote a fixed price for a working first version that does the core job.
- Agile improvements after launch. Once real people use it, you will know what to add next. Fund improvements in short cycles with a monthly cap.
This gives you a known cost for the part you understand and flexibility for the part you cannot predict yet.
How to choose: a quick checklist
| Question | Leans fixed price | Leans agile |
|---|---|---|
| Can you describe every step of the process today? | Yes | No, or only roughly |
| Do you run this process already, by hand or in spreadsheets? | Yes | No, it is new |
| Is the budget a hard limit? | Yes | There is room to invest as it proves itself |
| Will the software keep growing for years? | No, it does one job | Yes, it is a product |
| Can you give an hour or two of feedback every week or two? | Not easily | Yes |
Mostly in the left column? Ask for a fixed quote. Mostly right? Ask for agile with a cap. A mix of both? Use the hybrid.
Protecting yourself under either model
- Own the code. The contract should say the code and data belong to your business, and you should have access to them.
- Write acceptance criteria. For each feature, agree how you will know it works, in plain English.
- Agree a change process. How changes are requested, priced and approved, before the first one comes up.
- Pay against milestones. On fixed price, staged payments tied to working software. On agile, a cap per cycle and a review before the next.
- Plan for support. Software needs updates and fixes after launch. Ask what that costs before you sign.
Worked example: a cleaning company’s booking portal
A domestic cleaning company takes bookings by phone and text, then copies them into a spreadsheet and a shared calendar. The owner wants customers to book and pay online and see their upcoming cleans.
The process already exists and every step is known, so a short discovery turns it into a written scope: booking form, calendar, payment, customer login, reminders. That first version is quoted at a fixed price. After three months live, the owner wants a cleaner app showing each day’s route and a way for customers to add extras. Nobody could have specified those confidently at the start, so they are built in short agile cycles with a monthly cap.
Notice what the owner avoided. Had the whole thing been specified up front, the cleaner app would have been guessed at before anyone had used the booking system, and probably built wrong. Had the whole thing been agile from day one, the core booking system, which was perfectly predictable, would have been paid for by the hour with no fixed figure to budget against. Splitting the work let each part use the model that suited it.
The same pattern fits most small business software. The first version replaces something you already do by hand, so it can be specified and priced. What comes after depends on how people actually use it, so it is better funded in small, capped steps, with a review before each one. If a developer insists on only one model for everything, ask why.
Getting started
Our custom business software service builds tools like this for small businesses, and our web applications start from £1,999 for custom web apps, dashboards, portals and booking systems, with the exact price depending on scope. For typical price ranges, see our guides to web app development costs, booking system costs and client portals for small businesses. All our prices are on the pricing page.
Get the UK Website Project Brief Template (free)
A two-page template for briefing any UK web designer: sitemap, integrations, audience and deliverables. Cuts revision rounds in half.
No spam. UK GDPR compliant. We only use your email to send this resource, unless you tick the box to hear from us.
Frequently asked questions
Is fixed price or agile better for small business software? +
It depends on how well you can describe the job. Fixed price suits small, well-understood work such as a booking form or a simple portal. Agile suits new ideas and software that will keep changing. Many small businesses do best with a fixed-price first version followed by agile improvements.
Why do fixed-price software projects go over budget? +
Usually because the specification was guesswork. Once people see the software, they realise what they really need, and each change becomes a priced change request. A short discovery stage before the quote makes the scope knowable and reduces those surprises.
How do I stop an agile project costing too much? +
Set a firm cap per cycle or per month, agree what done looks like for the first usable version, and review working software at the end of every cycle before approving the next. Agile without a budget limit and decision points can drift.
What is a discovery phase in software? +
It is a short stage before building where the team learns about the problem: the users, the process, the constraints and the must-haves. GOV.UK guidance stresses not starting to build during discovery. For a small business project it can take days rather than weeks.
How much does Luxbranding charge for custom software? +
Our web applications start from £1,999, covering custom web apps, dashboards, portals and booking systems. The exact price depends on scope, and a clear written scope is what makes a fixed price possible. All our prices are listed on the pricing page.
