Getting a website built in Sunderland
What to ask about scope, ownership, ongoing care and local search before choosing a website proposal.
A website proposal is easier to judge when it begins with the business’s actual work. A garage needs a different enquiry journey from a shop, and a café may need visitors to check opening hours before anything else. Location gives the brief context; it does not make every local website the same.
Before comparing designs or prices, write down the main action the site should support. Then collect the information a customer needs before taking it. That short exercise gives you a way to assess a proposal beyond whether its homepage looks impressive in a presentation.
Bring the real job to the first discussion
Describe what the business sells, where it operates and who answers website enquiries. Bring examples of the questions staff repeat. If customers regularly ask whether a service covers their address or whether an item is in stock, the site should help answer that clearly.
List the systems already in use: booking software, a shop platform, a customer database or an email service. Note who owns the accounts. An agency cannot scope an integration properly from a logo on a slide; it needs to understand the workflow and the available access.
Show what happens after a customer makes contact. A form can be easy to use and still create work if it lands in an inbox nobody monitors. The project should include that handoff, including what the visitor sees if something fails.
Compare the whole scope
Ask each proposal to identify the pages, content work, design, build and launch support included. Photography, product data, copywriting and integrations are separate pieces of work even when they appear together on the finished site. Establish who supplies them and when they are needed.
A subscription and a build fee describe payment structures. They do not tell you the quality of the work or the responsibilities after launch. Compare the total commitment, the work included during that period and the process for changes. Ask for the assumptions in writing.
Our pricing page explains the models used to discuss a project without treating a broad category as a fixed quote. Your own brief determines the scope. A booking connection or a large catalogue may change that scope more than the number of visible pages.
Clarify ownership and access
Ask who will control the domain, hosting account, website files and third-party subscriptions. Find out what can be transferred, what depends on a paid service and what happens if you change supplier. These are practical project questions to settle in the written agreement.
Keep business accounts under business control where the arrangement allows it, and agree how the agency receives access. Avoid relying on one person’s private inbox for recovery details. The person who runs the business should know where essential access information is held.
Request a handover that someone can actually use. It might show how to update opening hours, replace a photograph or report a problem. If the site is maintained entirely by the studio, agree the route for requesting those changes and the expectations around urgent work.
Understand the local search work
For a Sunderland business, useful local information begins with accurate service and contact details. Explain whether people visit you, you visit them, or work happens remotely. State the real area served. Do not use photographs or addresses that imply a branch you do not have.
Google’s Business Profile guidance describes relevance, distance and prominence as factors in local results. Complete and accurate information helps Google understand a business. That does not make any agency able to promise a particular position or remove the effect of distance.
Area pages should answer a local customer’s practical questions. Does a service cover that location? Is collection available? Are there constraints to discuss? If the answers are identical everywhere, a clear service-area explanation may serve the reader better than a set of near-duplicate pages.
Ask how the site will be checked
Request a demonstration on a phone as well as a desktop. Try the important actions yourself. Read long service names, use the menu with a keyboard and check what happens after an invalid form entry. Real content often reveals problems that a short placeholder cannot.
Performance checks should cover loading, interaction and layout movement. Google’s Web Vitals overview explains these dimensions. Treat the measurements as part of the evidence alongside the actual customer journey, rather than accepting a score as the whole definition of quality.
Agree who checks content before launch. Dates, prices, service claims and opening hours need someone who knows the business. Design approval and factual approval are different jobs. A page can look finished while still containing an assumption that nobody has confirmed.
Plan the work after launch
Ask what the care arrangement covers and how it is reported. Updates, backups, monitoring, content changes and support can be packaged differently. Make the responsibilities visible, including the third-party services that have their own subscriptions or support arrangements.
Agree the first useful review after launch. Look at whether customers can complete the main task and whether enquiries contain the information staff need. Fix a confusing instruction or a broken handoff before adding more pages purely to make the site larger.
Full Lean’s Sunderland offer connects local website work with the existing web design service. A useful first discussion can start with the current site and one clear problem. You do not need a finished specification to explain what is getting in the way.
Questions
Is a subscription or a one-off build better?
Compare the actual scope, payment schedule, ongoing work and exit arrangements. Neither label tells you what is included or who will maintain the site.
What should we bring to a first discussion?
Bring the current website, the main action you want visitors to take, examples of customer questions, and a list of systems the site needs to work with.
Should every nearby town have its own page?
Only create a page when it helps explain a real service in that place. A useful area page answers practical questions rather than repeating the same copy with a new town name.
