Fixed price or hourly: how to choose for a web project

When you commission a website or an app, sooner or later you hear: “fixed price or hourly?” There is no answer that suits everyone. The two models simply share the risk in different ways. The rule is short: if the project can be described before it starts, ask for a fixed price. If it cannot, ask for hourly with a cap.

Fixed price: what you gain and what you give up

You gain predictability. You know what you will pay before we begin and can decide with numbers rather than hope. If the work takes longer than expected, that is the contractor's concern.

You give up flexibility. The scope is written down, and anything outside it is a separate request with a separate price. This is often taken as “extra charging”, but the price was worked out from a specific list. When the list changes, the calculation no longer holds.

The problem is rarely the fixed price. It is a brief that was too general.

There is a hidden side too: the contractor builds in a risk buffer. The vaguer the brief, the bigger the buffer. In other words, you pay for your own uncertainty.

Hourly: freedom in exchange for an open budget

You gain freedom. You can change direction midway without renegotiating anything. When you are learning as you go, that is real value.

You give up control of the bill. The first estimate is a guide, not a promise. It often looks smaller than the final figure, because the estimate is for the scenario where nothing goes wrong. There is also a question of incentive: with hourly pay, slower work earns more, even if nobody does it on purpose.

If you do choose this model, do three things:

• Set a cap. When a sum is reached, work stops until you approve.
• Ask for a report by task, not just a total of hours.
• Break it into short stages with a budget. If the limit is broken twice in a row, the estimates are not realistic and it is time to talk.

When a fixed price is safe for both sides

A fixed price is fair only after a clear description of the project. That means writing down the screens and what can be done on each, the roles and permissions, what data is collected, which outside systems it connects to and, most important, what is out of scope.

The list of what will not be done saves more arguments than the list of what will. After such a document the price is a commitment, not a guess. A price given after a short chat, with nothing written, is only the start of a negotiation.

This is how we work: we start with a free consultation, then you get an offer with a fixed price, timeline and scope, and payment is made in stages.

What to ask before you sign

For a fixed price:

1. 1Which document describes the scope, and can I read it before signing?
2. 2What is explicitly out of scope?
3. 3How are changes priced: at a fixed rate, or negotiated each time?
4. 4What happens if the schedule slips because of me?
5. 5Are there free fixes after handover, and how many?

For hourly:

1. 1What is the rate, and does it differ between people?
2. 2Is there a cap at which work stops for approval?
3. 3How are hours reported, and how often do I see them?
4. 4Who covers the hours spent fixing their own mistakes?
5. 5How many hours did the last similar projects take compared with the estimate?

The last question is the most useful. An honest contractor will say there is usually some overrun. An answer of “we always come in on the estimate” is either untrue or means the buffer is already in the rate.

Signs the quote will go over budget

• A price with no brief: a number given before it is written down what is being built.
• Round timelines: “three months” often means nobody broke the project into tasks.
• Unnamed integrations: “connecting to your systems” can be two weeks of work or six.
• No process for changes: a contract with no procedure for scope changes guarantees a dispute.
• A quote far below the rest: it usually describes a different project. The difference arrives later.
• One person, no backup and no access to the code: the risk is no longer financial.

A fair payment schedule

What matters is that payment is tied to finished stages, not to the calendar. A reasonable example:

• First payment at signing, when the scope is clear and accepted.
• Second payment at a working version you can open and try.
• Final payment at handover, when everything works on your side.

The last payment should not be token: it is your leverage at the end. Splitting payments on smaller projects is normal practice. And every quote should say clearly whether the price includes VAT.

The short answer

• You know what you want and it can be described: a fixed price after a clear scope.
• You do not know and will learn as you go: hourly with a cap, short stages and a report.
• Someone gives you a fixed price with no description: they are not taking the risk, only postponing the conversation about it.