Fixed-price vs hourly software builds: which one protects you

The short answer: an hourly software build is an open-ended meter that puts all the risk on you — if it takes longer than hoped, you pay more. A fixed-price build (quoted off a proper scope) puts the scope risk on the builder and gives you a number you can count on. For most businesses, fixed-price is the structure that protects you.

What's the problem with hourly billing?

Hourly sounds fair — pay for the work done. But on a build, it means you're funding an open-ended meter. If the work takes twice as long, you pay twice as much, and you carry the risk of every underestimate, misunderstanding and complication.

The incentive isn't aligned either. Under hourly billing, efficiency reduces the builder's revenue. That doesn't mean anyone's acting in bad faith — but a structure where "faster" means "paid less" is quietly pulling in the wrong direction. And the party paying by the hour is the one party with no control over how the hours are spent. You can end up funding a project that drifts, with no ceiling and no easy way to say "enough."

There's also the anxiety of it. Every meeting, every change, every question adds to a bill you can't predict. That uncertainty makes it hard to plan, hard to budget, and hard to relax into the project.

Why does fixed-price protect you?

With a fixed price, you know the number before the build starts. If it takes longer than expected, that's the builder's problem, not yours. The risk of scope and complexity shifts to the party actually doing the work — which is where it belongs, because they're the ones who can estimate and manage it.

You get budget certainty: a single number you can weigh against the value, plan around, and approve with confidence. And you get a builder motivated to deliver efficiently, because their margin depends on it rather than being eroded by it. The incentives finally point the same way — both of you want the thing built well and built without waste.

The catch: fixed-price needs a real scope

A fixed price is only meaningful if there's a proper scope behind it. Quote a fixed price on a vague brief and you'll get either a padded number (the builder pricing in the uncertainty) or a fight later when the scope's ambiguity surfaces.

That's why discovery and scoping come first — they're what make a fair fixed price possible. Without them, "fixed price" is just a guess wearing a confident face. With them, it's a genuine commitment grounded in a clear understanding of what's being built. If a builder offers you a firm fixed price without doing the work to understand your operation first, be cautious: either the number is padded, or the surprises are still coming.

A worked example of who carries the risk

Two builders quote the same job. One says "roughly $60,000, but it's hourly, so it depends how it goes." The other says "$75,000 fixed, off this scope." The hourly number looks cheaper, so it's tempting. But play it forward. The build hits the usual complications — an integration that's fiddlier than expected, a process that turns out to have three variations instead of one. On the hourly deal, every one of those hours lands on your invoice, and the "roughly $60,000" quietly becomes $85,000 with no ceiling in sight. On the fixed deal, the same complications are the builder's problem to absorb, because they agreed to a number.

The higher fixed figure wasn't the builder being greedy. It was them pricing the risk honestly and taking it off your plate. You paid a known premium to convert an uncertain, uncapped cost into a certain one you could budget against — and for most Australian small and mid-sized businesses, where a blown software budget isn't a rounding error, that certainty is worth paying for.

Won't a fixed price just be padded?

It's a fair worry — a builder carrying the risk will price some buffer in, and that's reasonable. The protection against being over-charged isn't switching to hourly (which removes the ceiling entirely); it's the scope. A tight, agreed scope leaves little room for padding because both sides can see exactly what's being priced. A vague brief is what forces a big buffer, because the builder is pricing every possible interpretation. So the answer to "is this padded?" is almost always "how good is the scope behind it?" Get the scope right and the price becomes something you can sanity-check rather than take on faith.

When can hourly make sense?

Fixed-price isn't the answer to everything. For genuinely open-ended, exploratory work — ongoing tweaks, maintenance, or a small experiment where scope really can't be defined — hourly or a retainer can be reasonable and fair. In those cases there's nothing firm to fix a price against, and paying for the actual work done is honest.

The distinction is whether the work can be defined. A defined build should be fixed-price off a proper scope. Ongoing, evolving care — the kind of maintenance a live system needs — often sits better on a retainer, where the point is availability rather than a fixed deliverable.

Related reading

• •How to scope a software project properly
• •Why "start small" beats a big-bang software build
• •For the bigger budgeting picture, see the real cost of business software.
• •Up to the pillar: getting software delivered right

The honest first step

Getting a fair fixed price starts with a proper scope, which starts with understanding your operation. Discovery is what makes a fixed-price build possible — and what protects your budget.

Tell us what you run, and we'll show you what's possible.