A revision adjusts agreed work; a scope change adds a new requirement. Establish the distinction before development and list exactly what the handover contains. Changing a heading within an approved page is a revision. Adding a booking engine is a separate feature request. Code delivery does not transfer ownership of third-party fonts, stock photographs or software licenses.
Use an acceptance record that distinguishes observed defects from requested additions. For each item, note the relevant page, the agreed behavior, the actual result and the next action. This makes a discussion about a failed form different from a new request for an appointment calendar. It also prevents ordinary corrections from being lost in a long list of unrelated preferences.
Before closing the project, have the owner or future maintainer locate a specific content file and identify the production account. They do not need to perform every deployment personally, but they should understand where control resides. Verify that third-party license records and setup instructions are included with the delivery material. If an account cannot be transferred, describe the practical consequence and agreed alternative. Clear delivery is not merely sending files; it is providing a usable path for the business to operate and maintain what it has received.
Define a revision in relation to an approved scope
A revision is an adjustment to work already included and agreed. That definition needs examples because different people use the word differently. Changing a headline, correcting an image crop or adjusting spacing on an existing section may be part of a revision. Adding another language, a new service page or a reservation engine introduces additional work and should be assessed as a scope change.
Agree how feedback is submitted. A grouped round works best as one list with the page or section, the observed problem and the desired outcome. If several client stakeholders are involved, appoint someone to combine their comments before sending them. This avoids a developer receiving two incompatible decisions about the same heading or layout.
Distinguish a defect from a new preference. A form that does not behave as agreed needs correction. Replacing an approved visual direction because a new stakeholder prefers another style requires a discussion about scope and timing. Clear acceptance criteria help both sides make this distinction without turning every conversation into a dispute.
Make delivery a usable handover
List the materials required to continue operating the site. Depending on the implementation, these may include a source repository or current source archive, content files, build instructions, deployment steps, domain and hosting account information, and a record of external dependencies. The exact list should match the actual system rather than a generic checklist nobody has verified.
Ask the delivery team to explain how a routine text change is made and published. Can the next maintainer find the relevant content, run the build and identify the production destination? If a management panel is not included, explain the editing workflow honestly. A blog structure does not automatically imply a browser-based editor.
Separate source-code ownership from third-party licenses. Fonts, stock images, templates and software packages can carry conditions that remain in effect after delivery. Record those licenses and any subscriptions or account restrictions. It is reasonable to receive the site’s original source while still respecting the terms attached to external assets.
Credentials require a different transfer method from ordinary documentation. Do not put secrets into public repositories, front-end files or a general handover PDF. Document which accounts and secrets are needed, then use an appropriate private account-management process for actual access. The objective is control and continuity, not exposing sensitive values to everyone who sees the source.
Close the project with observable checks
Review the agreed visitor journeys using real content. Open the main pages, use navigation on a phone, submit an invalid form and complete a valid enquiry in the intended environment. Confirm that success represents actual receipt or storage. Check language switching on a detail page, not only on the homepage, and inspect important links after the final deployment.
Keep a short delivery record listing what was reviewed, what was handed over and any owner-controlled external settings still needed. Distinguish local checks from production checks. A successful local submission does not prove that the live credentials and database are configured. If deployment depends on the owner’s domain or account authorization, record that dependency precisely.
Define what happens after acceptance. Which corrections are covered, how are later content changes requested and what maintenance is separately agreed? Avoid vague expressions such as lifetime support or unlimited revisions. A small, explicit set of continuing responsibilities is easier to operate than a broad promise with no defined process.
For Orvunweb, revision allowances and delivery estimates vary by package and are confirmed in the written scope. Treat these as planning boundaries that support a manageable project. The strongest handover is one that lets the owner understand the delivered website and gives another competent maintainer enough information to continue without reconstructing the project from scratch.
Practical checklist
- Group feedback by round
- List source files and licenses
- Confirm account access
A concrete example: Changing a heading within an approved page is a revision. Adding a booking engine is a separate feature request.
A boundary to keep clear: Code delivery does not transfer ownership of third-party fonts, stock photographs or software licenses.
Your next step
Tell Orvunweb about your project
