A fixed-price contract works best when you know exactly what you want and it can be written down in detail. An hourly contract, also called time and materials, works best when the requirements will change as you learn. Many good projects use both: a fixed price for a clearly defined first version, then hourly work for improvements.
The two models compared
| Fixed price | Hourly (time and materials) | |
|---|---|---|
| You pay | An agreed total | For the hours worked, at an agreed rate |
| Budget certainty | High | Lower, unless capped |
| Flexibility to change | Low; changes need a change request | High |
| Needs upfront | A detailed written scope | A clear goal and priorities |
| Risk of overrun sits with | The developer, mostly | You, mostly |
| Risk of cut corners | Higher, if the price was too low | Lower |
When fixed price works
- The scope is small and clear: a booking app, a stock register, a set of reports.
- You have written down every screen and rule.
- Your budget can’t move.
The trap: a fixed price on a vague scope. Every missing detail later becomes an argument about whether it was “included”.
When hourly works
- You are building something new and expect to learn as you go.
- Priorities may change based on what users say.
- The work continues over a long time, such as improving existing software.
The trap: no cap and no reports. Ask for weekly hours, a list of what was done and a monthly limit.
The mixed model
- Discovery, fixed price. A short paid phase to map the process and write the scope.
- First version, fixed price. Built against that written scope.
- Improvements, hourly. With a monthly cap and a list of priorities.
This gives you a known cost for the first release and flexibility afterwards.
How to protect yourself either way
- Written scope. List screens, users, reports and rules.
- Milestones. Pay against delivered, working parts, not dates.
- Acceptance testing. Agree how you will test each part before you sign off.
- Change process. How changes are priced and approved.
- Code and data ownership. Who owns the code at the end.
- Support. What happens after launch, and what it costs.
Questions to ask any developer
- What exactly is included in this price?
- How do you handle changes?
- How will we see progress each week?
- What happens if the project runs late?
- Who owns the code?
- What support do we get after launch?
How Ameya Artha helps
We start with a clear written scope, timeline and price, and agree the change process before work begins. See our software services