Skip to content
AspirecoStart
All answers

Working with us

Fixed price or hourly: how should a software build be priced?

The short answer

Fixed price, once the scope is understood — and not before. Hourly billing pushes every overrun onto you, while a fixed price quoted before anyone has looked is a guess. The honest sequence is an audit first, then a fixed-scope, fixed-price build against a working first slice.

Updated

Why hourly is a poor fit for a build

Hourly billing puts all the uncertainty on the buyer: when the work runs long, every extra week lands on you, and you cannot budget for it.

Why a quick fixed quote is no better

A fixed price quoted before the work is understood is a guess. Either it carries a large buffer, or the gap comes back later as corners cut.

The sequence that works

Look first. The free audit ends in a written scope with a cost range, so the first number you see is one that can be stood behind rather than one invented on a call. The build is then fixed scope at a fixed price, starting with a working production slice inside two weeks and continuing in weekly increments on staging you can watch.

After launch

Running and improving the system afterwards is different work, better suited to retained capacity: monthly, sized to the estate it looks after, and cancellable on a month's notice.

Asked next

What if the scope changes during a fixed-price build?

Then the change is scoped and priced in writing before it is built, like the original work. Weekly increments on staging make changes visible early, when they are cheapest to make.

Is time and materials ever the right way to pay for software?

For open-ended work with no fixed outcome — ongoing improvement, maintenance, experiments — capacity fits better than a project price. That is what a monthly retainer is for; a build with a defined result should have a defined price.