Why do you quote a fixed fee rather than a day rate?

Because of what each model rewards.

The incentive problem with time

On a day rate, every efficiency we find costs us money. Finish in six days instead of twelve and we have halved our own fee for doing the better job. Nobody sets out to game that, but over a career it shapes how carefully anyone examines whether a task really needs doing.

That has got worse rather than better. A lot of what used to fill a development week, the boilerplate and the scaffolding and the repetitive screens, is now genuinely fast. Charging by the day for work that has structurally sped up means either quietly slowing down or earning less for the same outcome. Neither is a good arrangement for the person paying.

A fixed fee removes the question entirely. We are paid for the result, so getting there efficiently is our problem and our benefit.

What it means for you

You know the cost before work starts, which matters for a business that has to plan. If the build takes longer than we estimated, that is our miscalculation and our cost, not a revised invoice. And the conversation at the end is about whether the thing works, rather than about the timesheet.

What it demands from us

A fixed price is only honest if the scoping is honest. That means we spend real time before quoting: looking at the actual process, the systems involved, what the exceptions are, and what your current licence tiers allow. Most projects that go wrong went wrong here, before any code existed, because somebody quoted from a description rather than from the process.

It also means we will sometimes decline to quote. If the requirement is still moving every week, a fixed price is a guess dressed up as a commitment. We would rather say so and suggest a smaller paid piece of scoping work first, or a monthly arrangement while things settle.

When the scope changes

It usually does, in small ways, and that is normal. Minor things we absorb, because pricing every small change is a miserable way to work together. Anything that meaningfully changes the shape of the build gets quoted as a variation before it is built, so you decide whether it is worth it.

What we do not do is start low and recover it through changes. That approach is common and it is the reason so many people expect the final invoice to be a surprise.

The version that goes further

Revenue share is the same principle taken to its conclusion. We build the system and take a percentage of the value it creates, so if it does not produce, we do not get paid. It does not suit every project, because the value has to be directly measurable, but where it fits it is the cleanest alignment available.