Why we use fixed-fee engagements

Hourly billing is the norm in software services. It is also a misaligned incentive structure.

When a vendor bills by the hour, every hour of work generates revenue. Slow progress, rework, and scope expansion are all profitable. The client bears the risk that the engagement will take longer than estimated. The vendor does not.

We bill by scope, not by time.

What fixed-fee requires

A fixed fee is only viable if the scope is defined before work begins. This forces a conversation that most software projects avoid: exactly what will be built, and exactly what is excluded.

This conversation is uncomfortable. It requires the client to commit to a scope they may not fully understand yet. It requires us to commit to a price before we have written a line of code. Both parties are making a bet.

But this discomfort is the point. The alternative — starting work before scope is agreed — is a bet made implicitly, with the terms only becoming clear when a dispute arises.

The architecture specification as the scope document

We define scope through the architecture specification produced before any build work begins. This document names every component, every integration, and every constraint. It is the basis for the fixed fee.

If the scope changes — new functionality, additional integrations, expanded user base — that change is assessed against the original specification and priced as a written amendment. The original price does not change retroactively.

What clients get

Clients who engage on fixed-fee terms know their total cost before work begins. There is no surprise invoice at the end of the month. There is no conversation about whether the work took longer than expected and what that means for the bill.

They also get a vendor whose incentive is to finish the scope efficiently — not to extend it. When work is done, the engagement moves to the partnership phase. There is no financial motivation on our part to let the build drag on.