What Does “Finished” Mean in Your Website Project?

A website project can be almost finished for a surprisingly long time. The pages exist. The photographs are in place. The designer has sent another review link. Then someone says, “It still doesn’t feel quite right,” and the next round begins.

Sometimes that hesitation is justified. The site may look complete while an important customer task still fails. Sometimes the team has never agreed what it is reviewing. Those situations need different responses, and “unlimited revisions” is a poor substitute for knowing which one you have.

A promise of unlimited revisions leaves the hard question open

Unlimited revisions sound reassuring when you are buying something you cannot yet see. You do not want to be trapped with a site that misses the brief. Fair enough. But an unlimited number of changes does not define the result those changes are meant to achieve.

A supplier can keep changing colours without resolving an unclear service offer. A client can keep introducing new stakeholders whose preferences contradict decisions made earlier. Both sides stay busy. Neither can explain what evidence would let them stop.

The better question is: what must this delivery do before we accept it? That includes the agreed design direction, content and customer journeys, with a way to demonstrate the important behaviours. It should be possible for the business owner to understand the checks without reading the source code.

This is a practical delivery process, not a substitute for legal advice about a contract. Its purpose is to make review useful while there is still time to act on it.

Three comments that ask for different work

Imagine a business reviewing a new service website. These are hypothetical comments, but the distinction is useful in a real review:

Calling everything a revision hides these differences. Calling everything extra work is just as bad. The classification must follow the agreed outcome and actual behaviour, not whichever label protects one side’s budget.

Useful feedback supplies an example. “The form is broken” becomes “On this page, using this device, I submitted these test details and saw a success message, but the agreed inbox received nothing.” That gives the supplier something to reproduce. Avoid including private customer information in the review when test data will do.

Write acceptance checks a client can actually run

Take the enquiry journey. “Working contact form” is too vague to settle many disputes. A clearer check might say:

A visitor can submit the agreed required information from the service page. Invalid or missing inputs receive understandable feedback. A successful submission reaches the agreed destination and shows the visitor an accurate confirmation. The journey can be completed using a keyboard on the agreed supported pages and devices.

That is still only one part of acceptance. It does not claim to be a complete accessibility audit, email deliverability guarantee or security assessment. It defines a specific journey that the client and supplier can demonstrate together, including failure behaviour instead of only the happy path.

Build a short review sheet around the actual project:

• The important customer tasks and what success looks like.
• The agreed content, page types and design reference.
• The devices and browsers included in the review.
• The person who consolidates feedback and makes the decision.
• The evidence required to close a defect and the process for handling a new request.

Keep each item concrete enough to inspect. “Looks professional” can be discussed during design review, but it cannot replace agreed examples. “All links work” should identify the journeys and destinations being checked. An acceptance sheet becomes another vague document if nobody can use it to make a decision.

Scope cannot excuse a broken result

The strongest objection to strict acceptance criteria is that clients often discover important needs by using the first version. They cannot describe every problem in advance. That objection is valid.

A supplier should not hide a fundamental usability failure behind “you never asked for that exact button behaviour.” Nor should an inaccessible interaction automatically be dismissed as an aesthetic preference. Investigate the barrier, the intended user journey and the applicable requirements. A missed requirement needs an honest discussion about responsibility and remedy.

Equally, discovering a valuable new feature does not mean it was included in the original delivery. A customer portal may be an excellent next step. It still introduces permissions, data handling, support and testing that a simple service site did not require. Pretending those implications are just another revision harms the project.

The process needs room for discovery, with recorded decisions. That might mean changing the agreed scope or deferring a feature. It should not mean silently lowering the standard of the work already promised.

Finish this release, then choose the next one

Before the final review, gather feedback into one coherent list. Resolve contradictions internally rather than asking the supplier to implement incompatible instructions from several people. Mark each item with the affected journey, the observed problem and the decision needed.

For WordPress development, that turns the review from an exchange of impressions into a demonstrable delivery: the pages, forms and editing workflow do the agreed jobs. Where the friction is ownership, handovers or competing requirements, Business Solutions addresses the process surrounding the build.

Then make the release decision explicitly. Fix unresolved defects, accept the demonstrated work and record which improvements belong next. A launch does not need to be the final change the business will ever make.

Finished should mean you can point to the agreed result and show that it works. If neither side can do that, another round of revisions is not yet a plan.