Fixed price or hourly: which suits a software project?
Fixed price suits work that can be described clearly before it starts: the scope is agreed, and the developer often carries more of the risk of it running long. Hourly suits work still taking shape, because direction can change as you learn. Each can go wrong: a fixed price on a vague brief can lead to disputes over what was included, and hourly work without a limit or reports can drift. Middle routes, such as a fixed price per stage, often work well.
How each one works
| Fixed price | Hourly | |
|---|---|---|
| What you agree | A defined scope for an agreed result | A rate for time spent, with the work described as it goes |
| Who carries the risk of it running long | Often the developer, if the scope was clear | Usually you, because you pay for the time used |
| Where it goes wrong | A vague brief: arguments about what was included, and each change can become a new negotiation | No limit and no reports: the bill can drift and progress can be hard to tell from activity |
How to choose
The deciding question is how clearly you can describe the finished job. If you can list the screens and rules and give real examples, so that two developers would picture the same thing, a fixed price is easier to agree. If you are still working out what you need, a fixed price tends to turn into arguments about what was included. The related answer on what to have ready before hiring a software developer helps you test this. Neither is automatically cheaper or safer; each moves the risk to a different side.
Guarding against each weak point
With a fixed price, the questions on how changes are priced and what the quote assumes are in the related answer on comparing quotes from software developers, which also shows how to set those assumptions side by side.
With hourly work, ask for a short report each period saying what was done, the time used and what comes next, and a say in what is worked on first. The related answer on what decides the cost of custom software has a question on how often you will see the time used and when to set a review point.
The middle routes
- Fixed price per stage. Each stage has its own scope and its own written checks, and you decide after each one whether to go on. The related answer on checking a developer's work covers approving a stage.
- Hourly with a cap. Time is billed as used up to an agreed limit; as the limit nears, work pauses for a talk about whether to stop, change direction or extend.
- A fixed first stage, then either way for the rest. The first stage shows what the job really needs, as the related answer on a minimum viable product describes.
- A fixed price for the main job, with a written change list. Each addition is priced and agreed before it is built.
Whichever you choose
As general advice, put the arrangement in the agreement: what each stage or period covers, how payment is tied to it and what you receive if the work stops partway. Check what the agreement says about payment and about ending it before relying on a verbal understanding, and ask a lawyer to read it before you sign. Ascent Vision builds software, so read this with that in mind. It does not publish prices.
Related answers
- How do you compare quotes from software developers?
- How do you check a developer's work before paying for more?
- What decides how much custom software costs, and why do projects run over?
- What is an MVP, and should a small business start with one?
- What should you have ready before hiring a software developer?
Custom software and apps
Off-the-shelf tools get you most of the way. When the last stretch is where the time goes, we build the part that fits: the dashboard, the portal, the internal tool or the app.