Fixed Price or Hourly: How to Budget a Software Project

Fixed price means you agree on a scope and a total cost before work starts, and that number does not move unless the scope does. Hourly, usually called time and materials, means you pay for actual hours worked at an agreed rate, and the total depends on how much work the project ends up needing.

Neither model is automatically the safer choice. The real risk is picking a model that does not match how well-defined your project actually is, and then being surprised when reality does not match the contract.

Why budgets slip even when everyone means well

Most budget overruns do not come from bad intentions. They come from small, reasonable-sounding changes — one more field on a form, one more integration, a redesigned flow — that each seem minor but were never priced or scheduled.

Under a fixed price contract, unpriced changes either get squeezed into the existing budget, which quietly erodes quality, or trigger a change order, which is where the friction usually shows up. Under hourly billing, changes just show up as more hours, which keeps things moving but can make the final number hard to predict.

When fixed price works

Fixed price fits a project with a scope that is genuinely settled: a clear list of features, a defined set of screens, and a low chance that requirements shift once work begins. That describes a well-scoped MVP more often than it describes a growing product.

It works best when it follows real discovery — wireframes, a written scope, and a technical plan — rather than a quick estimate based on a short conversation. A number given without discovery is a guess wearing the appearance of a commitment.

When time and materials works

Hourly fits work where you genuinely expect to learn and adjust as you go: early-stage products where the direction may change after user feedback, ongoing maintenance, or ambiguous work like partially rescuing an existing codebase. Forcing that kind of project into a fixed price just moves the risk into padding, since anyone pricing genuine uncertainty has to price in the uncertainty itself.

The tradeoff is that you need enough trust and enough visibility into progress to know the hours are going where they should.

The hybrid most teams end up with

In practice, most healthy engagements are not purely one or the other. A short, paid discovery phase — usually one to two weeks — produces the wireframes and scope needed to fix a price for the defined MVP. After launch, the relationship shifts to an hourly or retainer arrangement for iteration, fixes, and whatever comes next, because that phase is inherently less predictable than the first.

This also solves a trust problem: neither side is asked to fix a price on the unknown parts, and neither side is asked to write a blank check for the known parts.

What a paid discovery phase buys you

A short discovery engagement, even a paid one, is usually one of the cheaper ways to avoid a budget blowing up later. Discovery typically produces:

• A written scope that both sides can point back to when questions come up.
• Wireframes or flows that make “clear requirements” concrete instead of assumed.
• A technical plan that surfaces integration or data risks before they become surprises.
• A price that reflects the actual work rather than a rough guess.
• A shared understanding of what is explicitly not included.

That last point matters as much as the others. A scope that says what is out is often more useful than one that only says what is in.

How change requests should actually work

The problem with change requests is rarely the changes themselves — it is that most contracts have no defined process for them, so every change becomes a fresh negotiation instead of a routine step. A short change order that states what is being added, what it costs, and what it does to the timeline turns a potential conflict into a two-minute approval.

The absence of that process is usually a bigger warning sign than the billing model itself. A team that cannot describe how they handle scope changes before the project starts is unlikely to handle them well once it does.

Questions worth asking before you sign

A few direct questions tend to surface most budget risk before it becomes a real problem. Ask what happens, specifically, when a change is requested — not in general terms, but the actual steps. Ask how progress gets reported, and how often. Ask what is explicitly excluded from the current scope, not just what is included, since exclusions are where surprises usually hide. And ask what the estimate was based on: a short conversation, or an actual discovery phase.

Vague answers to any of these are worth treating as data, not just as a communication style.

What clients usually want

Clients care less about which billing model is used than about not being surprised. What they actually want is a number they can plan around, a clear process for what happens when something changes, and visibility into progress so the number stays trustworthy along the way.

They also want the freedom to change direction without every small adjustment turning into a negotiation. That balance is usually what separates a contract that works from one that becomes adversarial. If the project also involves deciding whether to build something from scratch at all, see build, buy, or extend: decide before you spend.

Mistakes to avoid

One common mistake is accepting a fixed price with no discovery phase behind it. That price is a guess, and guesses tend to be wrong in the direction that favors whoever made them.

Another mistake is choosing hourly billing with no visibility into how the hours are spent — no regular updates, no shared task list, no sense of progress until the invoice arrives.

It is also a mistake to treat every scope change as free just because the relationship feels informal. Even a “quick addition” costs real time, and pretending otherwise erodes the plan for everyone.

A simple example

A small e-commerce brand needed a custom checkout flow. Two weeks of paid discovery produced a clear scope and a fixed price for the build, which shipped on budget because nothing in it was a surprise.

After launch, they moved to a monthly hourly retainer for ongoing changes, because that phase was inherently harder to predict in advance. Splitting the work that way kept both phases honest instead of forcing one contract to cover two very different kinds of work.