Fixed Price Only Works With Fixed Scope
Fixed-price web projects get a bad reputation for the same reason: the price was fixed, but the scope was not. Vague requirements are filled in later with assumptions, and the disagreement shows up halfway through the build, when it is most expensive to resolve. By then the data model is settled and the migrations are written, and the change everyone now wants touches every layer. Most of these disputes start from a single vague line in the proposal.
The cost of one vague line
A single line in a proposal can hide weeks of work. “Product configurator” is the clearest example. The configurator on aux-garagen.de has 41 options, and most of the effort is in the relationships between them. Options depend on other options, and some combinations exclude each other. Some are physically possible but should not be sold, so something has to reject them before a customer sees a price. Price rules change over time, so a stored quote keeps the rules it was priced with, or it can no longer be reproduced. Currency and VAT handling is decided up front.
Server-side conversion tracking needs the same care. In our scope documents, the tracking line names every event, where it is sent from, how the server event is matched to the browser event, and what happens when a visitor refuses consent. Without that list there is no agreed way to tell whether tracking is done.
What goes into the document
We write the scope down before development starts and agree it in writing with the client: pages, functionality, integrations, the number of revision rounds and what is explicitly out of scope. It reads like a spec sheet. Every functional line answers the same questions before it goes in:
What triggers it, and what the expected result is
Who supplies the input: copy, images, product data, price lists, API credentials
What happens in the failure case: an invalid combination, refused consent, an unavailable third-party service
How the result is checked on delivery, in terms both sides can observe
What is explicitly not included in that line
Some lines are administrative, and they belong in the same document. Payment is 50% up front and 50% on delivery with 14-day terms, which only works if “delivery” is defined in writing.
Change requests and revision rounds
Fixed scope has a cost, and it lands on us as often as on the client. Halfway through a build someone has a better idea, and often it really is better. We write it up as a change request instead of absorbing it quietly. Absorbing it feels friendlier at the time, and it is why fixed-price work goes bad: the schedule slips without anyone deciding to let it slip, and it only becomes visible at the end, when there is no time left to discuss it.
The same distinction applies to revisions. A revision round adjusts something both sides already agreed to build; anything outside the document is a change request, whatever the email calls it. That line is the one most likely to be argued about, so it belongs in the document, before any deadline pressure. A standard site takes about a week, which leaves no room to redefine it halfway.
What the document can't fix
Content is the first gap. Page structure can be specified field by field while the build waits on the client’s copy and photographs. What helps is naming in the document what we need from the client, early enough that the dependency is visible. Third-party systems are the second gap: payment providers and ad platforms change their behaviour without notice, so each integration is named in the document.
The third case is a client who does not yet know what they want. A spec sheet forces early decisions, and some of them are premature. In that situation we suggest a smaller first build with a scope narrow enough to describe accurately, and leave the rest for a later round.
When the scope document is right, the final invoice matches the proposal plus the changes agreed in writing.
How we scope and price this kind of work is on the services page.
