Give your visitors
a clear next step.

Start with the fault, not the age of the design. A confusing service page or awkward contact step may justify a targeted repair. A replacement becomes a candidate when the existing setup cannot reasonably support the agreed requirements. We would check editing access, current structure and enquiry handling before recommending either route; neither is assumed in advance.

A focused landing page may suit one offer, one audience and one intended action, such as asking about a workshop. A wider site may be appropriate when visitors need to compare several services or understand the business in more depth. The decision starts with where visitors come from and what they need to decide, not a target number of pages.

Keeping them is the starting preference, not a reason to transfer everything. Before proposing any change, we would identify who controls the domain, where the site is hosted and how business email is managed. Any domain or hosting work needs an agreed change and recovery plan. Do not cancel an existing service or hand over account ownership simply to begin the audit.

We would assess the exact tools, account plans, access permissions and required handoff before confirming compatibility. List what information must move, where it should land and who should act on it. If the connection is unsuitable or unverified, the proposal should say so and discuss a simpler alternative or separately scoped integration. No tool connection is guaranteed by this page.

These arrangements should be explicit before work starts. The proposal would set out account control, the content and files handed over, editing access, third-party components and any conditions on transfer or reuse. It should also identify who handles renewals and how another provider could take over. Do not assume a design handover includes every account, subscription or source file.

The scope matters more than the page count alone: existing-site condition, content preparation, design requirements, forms, integrations, migration, testing and handover all need assessing. We would separate the proposed build work from hosting, domain renewals, paid tools and optional ongoing support. There is no standard price promised here; the next step is to establish fit and an agreed written scope.

A schedule would follow the agreed scope and a check of the dependencies, rather than a blanket turnaround promise. Required access, approved copy and images, feedback, migration decisions and third-party work must be accounted for. Name one decision-maker and identify missing inputs early. If a dependency changes, the delivery plan needs reviewing rather than quietly assuming the original dates still apply.

That path is part of the scoping conversation: what is collected, where it is recorded, who is notified, who owns the next action and what the visitor is told. Agreed testing should check receipt at the destination, not just the success message. Failure handling and an alternative contact route need defining too. CRM automation and follow-up sequences are separate unless the proposal expressly includes them.

The build can include agreed foundations such as page titles, descriptions, internal links and discovery checks. That is not an ongoing SEO campaign, and we make no promise of indexing, a Google position, AI recommendation or enquiry volume. If visibility is the main constraint, it needs its own assessment, scope and measurement plan rather than being implied by a new website.

We would agree that before launch. The handover should identify responsibility for content edits, form checks, software updates where applicable, backups, renewals and fault reporting. Any continuing support needs a defined scope, contact route, response expectations and cost. A completed build does not mean unlimited maintenance is included; you can assess a support arrangement or a handover to your nominated operator.