Fixed price or hourly: who takes the risk on your project

There's one question that shapes the outcome of a software project more than the programming language, the methodology or the size of the team: who pays if the estimate was wrong.

The two contracting models used in this industry answer that question in opposite ways. Neither is a scam and neither is the universal answer. But picking the wrong one for your situation is the most common cause of projects that end badly between people who acted in good faith the whole way.

The two models, no euphemisms

Fixed price. The scope is defined in writing, a number and a date are agreed, and that number doesn't move. If the team underestimated, the team absorbs the difference.

Time and materials (hourly). An hourly rate is agreed and the work is billed as it happens. If the project takes twice the hours expected, you're billed twice.

Everything else —the nuances, the hybrids, the blocks of hours— is a variant of those two. And the real difference between them isn't administrative. It's where the risk sits.

The incentive problem

Billing by the hour is the most widespread model in the industry and it has solid logic behind it: you pay for work performed, which sounds fair.

The problem isn't fairness. It's the incentive. In an hourly contract, finishing fast reduces the invoice. That doesn't mean people who bill hourly stretch projects on purpose; the vast majority don't. It means something subtler and harder to spot: there's no economic force pushing in the direction of finishing.

When a decision comes up between the simple solution that solves 90% of the problem and the elegant one that solves 100% and takes three more weeks, the hourly model doesn't help anyone pick the first. When the client asks for a feature of dubious value, the hourly model doesn't help anyone say no. Multiply that by two hundred small decisions across a project and you have the difference between four months and eight.

Fixed price flips the incentive, and it has its own cost. Whoever quotes fixed has a financial interest in the scope not growing, and that can turn into rigidity: arguments about whether some detail was included, resistance to reasonable changes, the temptation to solve something fast instead of solving it well.

No model lines up both sides' interests perfectly. What they do is let you choose which of the two misalignments you prefer.

When each one fits

Fixed price

It's the right model when the scope can be defined precisely before starting. That happens more often than people think: most business systems, portals, admin systems and process applications are perfectly definable if somebody sits down and defines them.

It fits especially when:

• You're replacing a process that already exists and works, even if it lives on paper or in a spreadsheet. If the process is there, the scope can be written.
• You have a budget that can't move. A board that approved an amount, a loan, an allocated line.
• It's your first project with that vendor and there's no trust built yet.

That last point matters more than it looks. Fixed price is a trust mechanism for new relationships: it protects you from an information asymmetry that is real, because the vendor knows how to estimate software and you don't.

Time and materials

It's the right model when the scope can't be defined because it's still being discovered. Typical cases:

• A new, unvalidated product, where what you build in month three depends on what you learned in month two.
• Extending your own team, where you're adding people to a process you already run.
• Ongoing work on a system in production, with a steady flow of small requests and shifting priorities.
• Genuine technical research, where not even the most honest vendor can know how long it will take.

In these cases, asking for a fixed price doesn't protect you: it guarantees an inflated budget. Anyone quoting without being able to define the scope has to add a big cushion, and you pay for that cushion whether or not it gets used.

The mistake that ruins fixed price

There's a very common way to ruin a fixed-price contract, and it's asking for one without having paid for discovery.

A vendor quoting fixed off a thirty-minute chat is guessing. They'll do one of two things: put up a high number to cover themselves, or put up a low number to win the work and then fight every change as an extra. You lose either way.

The healthy way is to split it in two: a short, paid discovery stage that produces a scope document with screens, business rules and acceptance criteria; and only then, the fixed price on that document.

That first stage usually costs 5% to 10% of the project and it's the best money you'll spend. It leaves you with a document that also works for getting comparable quotes from other vendors. If someone wants to give you the discovery for free, understand what that means: the cost is inside the project anyway, just not broken out.

How to handle changes without it turning into a fight

In fixed price, everything depends on having an agreed change mechanism before the first change shows up. Because changes will show up: it's normal and it's healthy, it means you're learning about the system while it's being built.

A mechanism that works has three parts:

1. A document that says what's out of scope. As explicit as the one saying what's in. Most arguments are about things nobody wrote on either list.
2. A simple procedure for quoting a change. The client asks, the vendor quotes hours and timeline, the client approves or doesn't. In writing, even if it's an email.
3. A rule for small changes. Formally quoting a two-hour tweak costs more than the tweak. A small monthly allowance for those keeps every detail from turning into a negotiation.

Without this, fixed price degenerates into the worst version of itself: two parties arguing over interpretations of an ambiguous document while the system goes nowhere.

How to keep an hourly contract under control

If the right model for your case is hourly, three controls make it manageable:

• A budget ceiling with a warning. Not a hard stop, but an agreement that at 70% of the expected budget you pause and review where things stand.
• Frequent, verifiable deliveries. Something working every two weeks, not every two months. It's the only real control: if every two weeks you see progress proportional to what was billed, the model is working; if not, you catch it early.
• Itemized hour reports. Not "40 hours of development", but on what. Not to audit anyone, but to understand where the effort goes, which is almost always useful information about your own business.

What we do and why

We work at a closed price for the agreed scope, with a discovery call before we quote. The reason is the one I've been laying out: in most of our projects —business systems, process applications, internal platforms— the scope can be defined, and when it can be defined, putting the risk of the estimate on the client has no justification.

It also has an effect that helps us: it forces a serious conversation about scope before anything starts. It's an uncomfortable conversation —you have to decide what's left out— but it's infinitely cheaper in week zero than in month three.

For ongoing work after launch, on the other hand, we use blocks of hours. Because there the scope genuinely can't be defined, and pretending otherwise would be selling a certainty that doesn't exist.

In one line

If the scope can be written, ask for a fixed price and don't accept a quote without discovery. If the scope can't be written yet, go hourly but demand deliveries every two weeks.

And be suspicious of anyone offering you a single model without having asked you anything about your project. The right answer depends on your situation, not on the vendor's commercial policy.