The proposal looked sensible. The scope was agreed. The price was approved.
Three weeks later, there's another invoice.
Perhaps a feature wasn't included. Perhaps an existing page requires more work than anticipated. Or perhaps something you've asked to change is now described as an extra.
The immediate reaction is understandable: wasn't that what the original quote was for?
Sometimes the additional cost is entirely reasonable. Sometimes the original scope wasn't clear enough. And sometimes a perfectly ordinary request exposes a conversation that should have happened earlier.
The useful question isn't simply whether the charge is fair. It's why the work wasn't accounted for, who agreed to it and what choices are available now.
Fixed price should mean fixed scope
A fixed-price website project normally describes a defined amount of work for an agreed fee.
That might include six pages, a responsive design, an enquiry form, basic technical SEO and an agreed review process.
It doesn't automatically include every future requirement that could reasonably be described as part of a website.
Imagine a regional engineering company commissioning a new site.
Adding the approved services and project examples to the agreed pages is part of the work. Introducing a searchable technical product catalogue midway through development may be an entirely new requirement.
The second task could be valuable. It also needs design, development, content preparation and testing that weren't necessarily included in the first.
A fixed price should protect both parties from uncertainty, not make legitimate new work free.
But the boundary must be understandable before the project begins. Our questions to clarify before signing a website agreement cover scope, approval and recurring costs.
An extra charge should have an explanation
There are several reasons a website price can change.
A new request. The business decides it needs another page, an integration or a feature not described in the original agreement.
A discovered complication. An old website has an undocumented integration, difficult content migration or technical restriction that wasn't visible during the initial review.
A third-party cost. A paid service, licence, hosting plan or other supplier charge becomes necessary.
An omission. Something reasonably understood to be included was never clearly documented.
These aren't interchangeable.
A new requirement should be quoted as additional work. A discovered complication needs an explanation of its implications. A third-party fee should identify what is being purchased, who owns the account and whether the cost recurs.
An omission requires reference to the original proposal and discussions, rather than an automatic assumption that the client must pay more.
Corrections are not the same as new requirements
This is where projects can become uncomfortable.
Suppose the approved design specified a mobile navigation menu, but the delivered version doesn't work properly on a phone.
That's not the same as deciding, after approval, that you'd like a member-only customer portal.
Similarly, correcting a factual mistake introduced during development differs from adding an entirely new service.
The treatment of corrections and revisions should follow the agreement. If a deliverable doesn't meet the agreed specification, it shouldn't casually be reclassified as an optional improvement.
On the other hand, reopening an approved design direction or expanding the site significantly may affect both time and cost.
Our article on avoiding the endless revision loop explains how to keep those decisions manageable.
Ask for the impact before approving the work
A useful change request needn't be complicated.
It should identify the requested change, why it's outside the existing scope, the additional price, any effect on the timetable and what happens if you decide not to proceed.
For example:
"The original project includes a standard enquiry form. The requested integration with your CRM adds a separate development and testing task. We can quote for that now or leave the existing form in place for launch."
That gives the client a real decision.
It is considerably better than discovering the charge after the work has been completed.
Where changes are discussed over the telephone, confirm the decision in writing. Neither side should have to reconstruct a commercial agreement from scattered messages weeks later.
Don't overlook the less visible costs
A website quote should also distinguish between the initial build and recurring services.
Domain renewals, hosting, paid tools, maintenance arrangements and additional development may have different charging structures.
Check whether prices are quoted with or without VAT, whether relevant third-party costs are included and when payments become due.
If the website uses subscriptions, ask which are necessary and what happens if you cancel them.
If the site is being rebuilt, confirm who is responsible for migrating existing content and protecting important URLs.
These details are rarely the most exciting part of commissioning a website. They are considerably more interesting when nobody has to argue about them later.
What if the extra invoice has already arrived?
Start with the agreed scope, proposal and any written change approvals.
Ask the supplier to explain which additional work the invoice covers, when it was authorised and why it falls outside the original price.
If the work was discussed but the cost wasn't, resolve that misunderstanding before approving further changes. If the work has not started, ask whether it can be deferred or simplified.
A professional relationship shouldn't depend on one party accepting a surprise invoice to keep the project moving.
At Smartcon Works, the intention is to agree the work and price before the build, with additional requests discussed separately when they arise.
A good project doesn't need to be free of changes.
It needs changes that are understood before somebody pays for them.