Who gains if the project drags on

There is one question worth asking any technology provider before signing: who benefits if this takes longer?

If the answer is “the provider”, the rest of the conversation is decoration.

A block of hours rewards the opposite of what you want

When you bill for time spent, the provider invoices the same whether your problem is solved in three weeks or in three months. Actually, no: three months invoices more.

Nobody has to be dishonest for that to do damage. Inertia is enough: the research that could be cut short is not cut short, the hard decision gets postponed, the debatable refactor happens because there are hours available. Nobody lied; there was simply nothing pushing the other way.

And on the client side the opposite reflex shows up: since every hour is paid for, you start watching the clock instead of the problem. Long conversations get avoided — usually the ones that were most needed. Both sides end up optimising the wrong metric.

“But then all the risk is yours”

Yes. That is the point.

If we agree a scope and it turns out to be more work than expected because we estimated badly, that mistake is ours and we absorb it. It is the right incentive: it forces us to understand the problem before committing, which is exactly what the discovery stage is for.

A provider billing by the hour does not need to understand your problem before starting. They can begin on Monday and find out as they go, on your money. We cannot: if we did not understand, we lose.

What has to be agreed for this to work

Charging for scope without defining the scope is a trap — the provider who later bills every request as “out of scope”. So three things have to be agreed in writing:

What is in and what is out. Not a list of features: the business problem the solution has to resolve. Features change while the problem stays the same.

What “finished” means. A condition verified in the client’s reality, not in the test environment.

What happens when the scope changes. Because it will. A change midway is not a problem: a change appearing on the invoice without you deciding it, is. It gets quoted separately, shown, and you decide.

With those three written down, the model holds on its own. Without them, any model ends badly.

Where time-based billing does belong

None of this means the hour is always the enemy. It means you do not bill by the hour for something with a definable deliverable. When there is no such deliverable, the model changes — and it should:

Support and evolution. There is nothing to close: the system is in production, and what gets agreed is availability and response times. That works by service or by blocks of hours, and rightly so — nobody can budget a year of incidents in advance.

Products in continuous change. Some products never finish, because the business keeps moving. There the work goes in cycles, with priorities reviewed with you at each one.

The difference from the block of hours described above is not accounting, it is direction: in these two cases there is no ending that someone could be delaying. In a project with a scope, there is.

In short

The billing model is not an administrative detail you look at last: it is the first statement about whose side the provider is on.

Ask who gains if the project drags on. The answer tells you more than any proposal.