Fixed price or hourly billing: why we never bill by the hour

Fixed price or time and materials: the definition in two sentences

A time-and-materials contract bills the hours or days developers spend. A fixed-price contract bills a defined outcome (a scope, a deadline) at a price agreed in advance. In the first case the client carries the risk of overruns. In the second, the supplier does.

The distinction looks simple. It still decides who benefits from going fast, who benefits from stretching the work, and who pays when something unexpected happens. That is why we never bill by the hour, and why this article explains when that choice is right and when it is not.

Comparison: time and materials versus fixed price on six criteria

The comparisons published on this topic agree on the first four rows. The last one is the least discussed, and it is the one that matters most today.

Why AI makes hourly billing harder to defend

A coding assistant changes the relationship between time spent and value delivered. A feature that took three days can take one. The link between billed hours and delivered value loosens, and that loosening works against the client under time and materials: the supplier who works faster earns less, the one who works slower earns more.

This is not an accusation of bad faith. It is a structural effect. When revenue depends on hours, a productivity gain becomes lost income for whoever achieves it. Under fixed price it becomes margin, and part of it can be passed to the client as price or scope.

To see what AI really changes in a project, read our article on shipping a product in 90 days. The takeaway here: the faster execution gets, the more the precision of the scope becomes the real subject.

How we scope a fixed price

A fixed price is only worth its scoping. Here is the sequence we follow, in order.

1. Define the observable outcome. A sentence such as “a user can do X and see Y”, not a list of technical features.
2. List what is excluded. Every written exclusion avoids an argument later.
3. Set the deadline. Our projects aim for about 90 days between scoping and production.
4. Name the assumptions. Data access, availability of a counterpart, third-party services: any assumption that fails triggers an explicit discussion.
5. Plan a change mechanism. A scope addition is priced before it is built, with what it replaces or delays.
6. Define acceptance. Acceptance criteria are written before development, not after.

This method does not remove uncertainty. It makes it visible and gives it an owner. You can compare this logic with our plans and pricing, which are built on it.

When a fixed price is NOT the right choice

A fixed price is the wrong tool in four situations. We decline them or redirect them.

• The need is not understood yet. If you cannot describe the expected outcome in one sentence, a fixed price only hides the uncertainty. A short exploration phase, billed separately, is more honest.
• The scope changes every week. A product whose direction depends on daily user feedback fits poorly with a frozen specification. Time and materials with a monthly cap suits it better.
• You want extra hands in your own team. If the goal is to add a skill to an existing team that directs the work, that is staffing. Time and materials is the natural model.
• Maintenance is the subject. An application already in production needs interventions of varying nature. A monthly maintenance package with a defined volume works, an “all inclusive” fixed price does not.

The hybrid model, often cited by suppliers, covers part of these cases: the clear scope at fixed price, the grey zone under a capped time-and-materials arrangement. It demands more discipline on both sides, because the border between the two zones has to be written down.

Five questions to ask before signing, whatever the model

These questions apply to time and materials as much as to fixed price. A supplier who answers them precisely has scoped projects before. To estimate the technical part of a budget, also see the stack choices and their costs for a Swiss MVP.

A fixed price moves risk, it does not remove it

A fixed price does not protect against poor scoping. It simply makes the other party pay for it. If the supplier underestimates, quality or testing gets squeezed. If the client over-specifies, they pay a risk margin for features they may never need.

That is why fixed price works best when the supplier has delivered comparable products and knows their own estimation gaps. Ask the question: how many similar projects, and what gap between estimate and actual? A vague answer is information.

The cost of an AI feature deserves particular attention, since it includes items that do not exist in classic software, such as evaluation and inference. Our analysis of the real cost of an AI feature in production details them. A serious fixed price includes or excludes them in writing.

Five warning signs in a commercial proposal

Whatever model is announced, certain wordings reveal insufficient scoping. Here is what we spot first when we review a proposal a client has received.

• A scope described with vague verbs. “Setup”, “integration” or “optimisation” without an observable outcome cannot be accepted or rejected.
• No exclusion mentioned. A proposal with no written exclusion leaves every future disagreement to be settled by bargaining power.
• A fixed price that never moves with the scope. If removing a feature does not change the price, the price was not built from the scope.
• Time and materials with no cap and no review point. Without a monthly cap and a regular review, the budget becomes an estimate nobody is bound to respect.
• A schedule with no intermediate milestone. A project of several weeks with no interim demo pushes the discovery of problems to the end, when they cost the most.

None of these signs alone proves a supplier is poor. Several together suggest the risk has not been shared, only moved onto you.

The mistakes we see on the client side

The choice of billing model is only part of the subject. Three mistakes come up often, regardless of the contract signed.

Choosing the model on the starting price. Time and materials looks cheaper because its initial price is a low estimate that reality rarely corrects downwards. Compare likely final budgets, not first-page figures.

Confusing flexibility with not deciding. Time and materials lets you change your mind, but every change consumes time and therefore budget. A client who does not decide quickly pays for the indecision at the daily rate.

Forgetting the period after delivery. A product in production needs fixes, monitoring and adjustments. If the contract is silent on them, those costs arrive as a surprise, whatever the model.

What we recommend depending on your situation

• You are launching a product and the outcome is clear: fixed price, with written exclusions and defined acceptance.
• You are exploring a fuzzy need: a short exploration phase, then fixed price on what comes out of it.
• You are reinforcing your team: time and materials, with a cap and a monthly review.
• You have an application in production: a maintenance package with a defined volume, plus quotes for changes.

Our rule is simple: if we cannot describe the deliverable, we do not quote, we scope first. See our work to find out what this framework produces in practice.