There are two common ways to structure a software project, and the choice affects budget, flexibility and stress. Neither is better in the abstract. The right one depends on how well you understand what you need.
Fixed scope
You agree what will be built, when, and for how much, before work starts.
It suits well-defined problems, where you know what you need and what "done" looks like. A clear internal tool, an integration between two known systems, a defined set of screens.
The upside is predictability. You know the cost and timeline up front, and the supplier carries more of the risk of overruns.
The risks are rigidity and false precision. If you learn something halfway through, changing the plan means a change request, and a fixed price is only as good as the scope behind it. A vague scope with a firm price tends to end in disagreement.
Phased delivery
The work is split into stages. You commit to the first stage, learn from it, and decide what comes next.
It suits larger problems, new ideas, or situations where you will learn a lot from real use. It also suits organisations that want to spread spending and see progress early.
The upside is flexibility. You can change direction based on what you learn, and you get working software sooner.
The risks are open-endedness and drift. Without a clear budget and decision-maker, phases can multiply. Phased work needs discipline on both sides.
A sensible middle path
Many projects work best as a hybrid:
- A short, fixed-price discovery phase to understand the problem and define a first release.
- A fixed-scope first release, small enough to be well-defined.
- Further phases agreed one at a time, each with its own scope and budget.
This gives you cost certainty where you can have it and flexibility where you need it.
Keeping control either way
- Name one decision-maker on your side who can answer questions and say yes or no quickly.
- Insist on regular demos of working software, not just status reports.
- Keep a change log so every change, and its cost, is visible.
- Agree what "done" means for each stage, in writing.
- Set a budget ceiling for each phase.
A worked example
Imagine a business wants a customer portal with document sharing and request tracking. A fixed-price approach works if the screens, rules and integrations are already clear. If not, a sensible path is a short paid discovery, a fixed-price first release containing only sign-in, document sharing and request status, and then a second phase for payments and reporting once real customers have used the first. You commit to a small amount each time, and each step is informed by the last.
Contract basics worth checking
Whichever approach you choose, look for: a clear definition of what is delivered; how changes are requested, priced and approved; payment tied to milestones rather than dates alone; what testing and acceptance involve; who owns the result; and what support is included afterwards.
Questions to settle before you start
What is the first release, exactly? What happens if scope changes? How are changes priced? What does support cost afterwards? Who owns the result?
If you are not sure which approach suits your project, we are happy to talk it through. Tell us what you are trying to improve, or see how we work.