Why we quote fixed scope, fixed date, fixed price

Most software contracts are written so that the vendor carries none of the risk. Hours are billed as they are spent, scope drifts as the project runs, and the client discovers the real price somewhere around month four. The incentive is backwards: the slower the build, the larger the invoice.

We quote differently. Before a project starts, we write a technical specification that names every screen, every integration, and every acceptance criterion. That document takes one to two weeks and is a paid engagement on its own. It is also the thing that makes a fixed price possible.

What the specification covers

• Every user-facing screen and the states it can be in
• Each third-party integration, with the specific API and auth model
• Data model and migration path from whatever exists today
• Acceptance criteria per feature, written so they can be tested
• What is explicitly out of scope for version one

Why this protects the client

A fixed price moves the risk of a bad estimate onto us. If the build takes longer than we thought, that is our problem, not a change order. It also forces an honest conversation early: when a feature is expensive, you find out during scoping, when cutting it is free, rather than in month three when it is not.

What it costs

Speed at the start. A discovery phase feels slower than a team that starts coding on day one. It is not — it is the same work, done before it becomes expensive to change.

If a vendor cannot tell you what your project costs, they do not yet understand what you asked for.