Guide
What to plan before a website build, and after launch
By Mavrin Labs. Published . Last updated . How this guide was researched and checked.
Decide four things before a website build: who each page is for, what one job it does, where an enquiry goes after it arrives, and which addresses must survive the move. Design sits on top of those answers. This guide works through each of them in order.
What should you decide before a website build begins?
Four decisions shape a website build, and all of them come before layout. Name the audiences the site serves, give every page one job, plan the route an enquiry takes after it arrives, and list the addresses that have to keep working. Everything visual sits on top of those.
The common failure is not an ugly site. It is a site that looks finished and loses work. An enquiry arrives in an inbox nobody owns. The customer record is retyped from an email. A page tries to serve three audiences and persuades none of them. Old addresses stop existing, and the standing those pages had built goes with them.
None of that is a design problem, which is why it survives a redesign. Each item is a decision somebody has to make and write down. Make them first and the build becomes straightforward, because every later question has an answer to refer to.
A site that looks finished and loses enquiries is the normal outcome of planning the design before planning the work the site has to do.
Map each audience to the question it arrives with
Start from the people who will arrive and what they came to settle. Most small-business sites serve three or four distinct arrivals, and each one needs a page that answers quickly rather than a page that introduces the business.
- Ready to act
- Knows what they want and is checking you are credible and reachable. Needs proof, a clear route to book or ask, and nothing in the way.
- Comparing options
- Knows the problem, not the answer. Needs the approaches compared honestly, including when yours is the wrong fit.
- Still diagnosing
- Has a symptom rather than a problem. Needs plain explanation first, and a next step that is reading rather than buying.
- Returning or referred
- Was sent by somebody or is coming back. Needs the specific thing they were told about, found in one step.
Write the question each audience arrives with in their own words. Those sentences become headings, and a heading written that way is easier to answer honestly than a heading invented to sound impressive.
Give every page one job
A page does one job: it answers one question for one audience and offers one next step. That rule settles most structure arguments, because a page that needs two jobs is two pages.
- The page states its subject in the first heading and answers it in the first paragraph.
- One audience is addressed, and the page says who it is for if that is not obvious.
- One next step is offered, and it is the step that audience is ready for.
- Nothing on the page exists only because a competitor has it.
- The page would still make sense to somebody who arrived on it directly from a search result.
The last item matters more than the navigation does. Most visitors never see your home page, so every page has to work as a first impression on its own.
What happens to an enquiry after it arrives?
An enquiry should arrive in one place with one owner, create a record in the system that holds your customers, acknowledge the sender in terms they recognise, and appear on somebody's list of things to do. Decide each of those before the build, not after it.
The route is where sites leak. A form that sends an email is only the first step, and an email is not a record. If the details then have to be retyped into the system that holds your customers, that retyping is both an hour and a source of mistakes, and it happens on every enquiry for as long as the site exists.
Plan the unhappy paths too. Decide what you want to happen when a delivery fails, when somebody submits the same enquiry twice, and when a field arrives empty. Joining those systems dependably is its own piece of work, and the systems integration page describes it.
Protect what the old site has earned
A rebuild moves addresses, and search engines, links and bookmarks all point at the old ones. Treat the address list as a deliverable: export it before the build, map every old address to its closest new equivalent, and apply a permanent redirect for each.
- Every address on the old site is listed before the build starts.
- Each one maps to its closest equivalent, or to the nearest useful parent when no equivalent exists.
- Each mapping is a permanent redirect, applied once and never chained through a second one.
- Pages that are being dropped are a deliberate decision, recorded with the reason.
- The list is tested after launch, address by address, not sampled.
Resist the temptation to send everything to the home page. A redirect to a page that does not answer the original question is a dead end for the reader and reads as a dropped page to a search engine.
How do you check the finished site?
Check the finished site against published criteria rather than against taste. Accessibility and performance both have public, testable standards, so you can hand a builder a list and compare the result against it. Both are also far less work to meet during the build than to retrofit once the templates are finished and signed off.
Accessibility is the first of those. The published accessibility guidelines set out criteria you can test: text that contrasts with its background, every control reachable from the keyboard, images described for somebody who cannot see them, and a page that still works at a large text size. Fixing those after launch usually means revisiting the same templates twice.
Performance is the second, and the measure that matters is what a visitor on a phone experiences on an ordinary connection rather than what the site feels like on the machine it was built on. Test on a real device before you accept the work.
- Every page has one main heading that names its subject.
- Text contrasts with its background, and the page is usable at a large text size.
- Every control and link can be reached and operated from the keyboard alone.
- Images carry a description, or are marked as decoration.
- The pages a visitor reaches first are tested on a phone on an ordinary connection.
- Forms and booking routes are tested end to end, with the delivery confirmed by the person who will receive it.
Standards behind this guide
The accessibility criteria above come from the published web accessibility guidelines, which are maintained in the open and written as testable statements rather than advice (the guidelines, opened and read on Thursday, October 8, 2026).
For how search engines read a rebuilt site, including what a permanent redirect signals and why one address per page matters, the documentation for site owners is the primary reference (the search documentation, read on the same date).
Neither reference tells you what your site should say. Both tell you how to check that what it says can be read, by a person and by a machine.
Next steps
If the planning above points at a build, websites and e-commerce is the service that covers it, and how engagements work sets out the stages and where the investment is agreed. If your enquiries already arrive but then stall between systems, the systems integration checklist is the more useful guide, and the systems decision framework helps if you are not yet sure which problem you have.
A site planned this way gives hours back to the people answering enquiries, because the details arrive where they are needed instead of being retyped. Mavrin Labs builds and plans this work for businesses and nonprofits anywhere, meeting clients in person in Sarasota and Manatee counties and working by video elsewhere.
Frequently asked questions
How much of this has to be decided before design starts?
Decide the audiences, the purpose of each page and the route an enquiry takes before anyone draws a layout. Those three shape the structure, and changing them later means redrawing pages and rewriting copy. Visual choices can wait, because they sit on top of a structure rather than creating one. Owners who reverse that order pay for the same page twice: once as designed, once as rebuilt when it turns out nobody could tell what the page was for.
What should happen the moment an enquiry arrives?
An enquiry should land in one place where somebody is responsible for it, create a record that holds who asked and what they wanted, and send an acknowledgement the person recognises. Decide which of your existing systems owns that record before launch. If the answer is a shared inbox nobody owns, you have found the gap that loses work, and no amount of design on the page in front of it will close that gap.
Do I need a new system to connect the site to my records?
A new system is rarely the answer. Most businesses already run a tool that holds customer records, one that handles scheduling and one that handles invoicing. The planning job is deciding which of those owns each piece of information and how the site passes it across, so nobody retypes it. Replacing a tool your staff know is a much larger project than connecting it, and it should be a separate decision with its own reasons.
What happens to my search results when the site changes?
Search results follow your addresses, so every address that changes needs a permanent redirect to its closest equivalent. Write the list of old addresses before the build, map each one to its new home, and keep the list as a deliverable rather than an afterthought. Pages that quietly disappear take their accumulated standing with them, and the usual symptom is a site that looks better and brings in less work than the one it replaced.
Who should own the site after launch?
One named person inside the business should own the site after launch, with a written note of who to contact for what. Ownership means someone decides when content changes, notices when a form stops delivering, and holds the accounts the site depends on. Agree that before the final invoice. A site with no owner drifts within months: details go stale, a broken route goes unnoticed, and the next build starts from a worse position.
What should a handover include?
A handover should include the accounts and access in your own name, the list of redirects applied, the structure of the site with the purpose of each page, where enquiries are delivered and who is responsible, and plain instructions for the content you will edit yourself. Ask for it in writing at the start of the project rather than at the end, because a handover written into the scope is a deliverable, and one requested afterwards is a favour.
Who writes these guides
Mavrin Labs delivers client work as a team in mixed roles, led by our founder. The people who write these guides are the people who build the systems described in them, and every page is reviewed before it is published.
Which hours would you take back first?
Send Mavrin Labs one workflow that is costing you the most time, and the reply comes back by email from the people who would build the fix.
Start a conversation