Learn: the web, apps and software projects, explained /
Fixed-price vs hourly software development
Fixed-price development means you agree the scope and the total in advance; hourly means you pay for the time spent as work happens. Fixed price suits well-defined projects and gives budget certainty, while hourly suits uncertain or evolving work and gives flexibility. Neither is better in general: the right model depends on how clear the scope is.
How fixed price works, and what it costs you in flexibility
You and the developer agree a written scope and a single total. The developer carries the risk that the work takes longer than estimated, and you know your commitment before anything starts. That certainty is the main reason to choose it.
The trade-off is rigidity. The scope has to be clear up front, a developer facing uncertainty may build a safety margin into the estimate, and anything outside the written scope needs a formal change. If you cannot yet describe what you want, fixed price will not fix that.
How hourly works, and where it goes wrong
You pay for the time actually spent. You can start quickly, change direction as you learn and stop whenever you choose. For research, prototypes and open-ended improvement, that freedom is worth a lot.
The trade-off is that the final total is unknown at the start, and the incentives are less aligned: slower work is not penalised. Hourly works well with regular reporting, an agreed estimate or ceiling to review against, and a team you trust.
When each model fits
Fixed price fits work you can describe: a business website, a booking flow with known rules, a defined integration. The clearer the scope, the better it works. Hourly fits discovery, a product whose requirements will change as users react, and ongoing maintenance with an unpredictable workload.
Many projects use both: a short paid discovery or scoping step, then a fixed-price build of the part that is now well understood, then ongoing work as needed. Choosing per phase is often more honest than choosing once for everything.
How change requests work under fixed price
A change request is anything that is not in the written scope: a new feature, a different integration, a redesign of an approved screen. Clarifying how an included feature should behave is not a change; adding something new is.
The process is simple. You describe the change, the developer states in writing how it affects time and cost, and you approve before work begins. You can also swap, dropping one item to make room for another. Done well, change requests are not adversarial; they keep both sides honest about what was agreed.
FAQ
Is fixed price or hourly cheaper?
Neither is cheaper by nature. Fixed price makes the total predictable and moves estimating risk to the developer; hourly can cost less when the work turns out smaller than expected and more when it grows. What matters is how well the scope is understood.
What if I want to change something halfway through a fixed-price project?
You raise a change request. The developer explains the effect on schedule and cost in writing, and the work proceeds once you approve. Small clarifications inside the agreed scope do not need one.
Which is better for a startup with an unclear idea?
Usually an approach that begins flexible: a short discovery or a small first version, then fixed price for the parts that have become clear. Locking a fixed scope around an untested idea tends to lock in the wrong thing.
Can I combine fixed-price and hourly work?
Yes, and it is common. A fixed-price build for the defined core and hourly or retainer work for later improvements is a sensible split, as long as each part has its own written terms.
Does fixed price mean lower quality?
It should not. Quality comes from clear acceptance criteria and testing, which a written scope makes easier to demand. The risk is on a vague scope, where there is pressure to cut corners to stay within the total.