How to choose a website development company

Start with the decision your website must help someone make

Imagine receiving three website proposals. One promises ten pages, another offers a custom experience, and a third includes SEO and unlimited support. The totals are different, but the proposals do not yet describe the same job. Choosing from the prices alone means choosing assumptions you may discover only after work begins.

Start with a short business brief. An interiors studio may need visitors to understand its services, inspect completed work and request a consultation. An event business may need to turn an occasion, date and guest count into a usable enquiry. Those are different journeys, even if both websites have five pages.

Name one primary customer action and the information someone needs before taking it. Then describe what happens after that action: who receives the enquiry, where it is recorded and how the team follows up. This gives a development partner a problem to solve and gives you a way to judge the proposal.

• Audience: who is visiting, and what are they trying to find out?
• Main action: request a quote, book, buy, apply or start a trial.
• Business handoff: which person or system handles the next step?
• Starting point: existing content, brand assets, website and useful search traffic.
• Constraints: budget, launch date, integrations and time your team can contribute.

Inspect live work and ask what the team actually delivered

A portfolio screenshot shows a design at one moment. Open the published website on your phone and follow a customer's route. Can you understand the offer, find relevant evidence and reach the next step? Explore more than the homepage. A service page, product detail or enquiry flow often tells you more about the work.

Ask the company to explain its role: discovery, writing, design, development, integrations and ongoing maintenance. Ask what the client supplied and what constraints shaped the result. A team that explains a decision clearly gives you more useful evidence than a gallery with no project context.

Our Sunasa Interiors and Fiesto project pages describe two different enquiry journeys. Use them as examples of what to ask about, rather than evidence of a claimed conversion uplift. Our Playground contains design explorations, labelled separately from client work. Make that distinction when evaluating any supplier's portfolio.

If a team presents commercial results, ask how they were measured, over what period and what else changed. With permission, speak to a previous client about communication, handover and support. Relevant experience helps, but a similar visual style alone does not demonstrate that the team can deliver your required functionality.

Turn broad promises into a scope you can check

Words such as responsive, custom, SEO-ready and supported are starting points for questions. Ask what each promise includes and how it will be demonstrated. The proposal should name the page types, content responsibilities, editable areas, forms, integrations, review rounds and launch work.

For example, an enquiry form is not fully described by saying contact form included. Specify required fields, where messages go, what the visitor sees after submission and what happens when delivery fails. An integration needs its destination, required data and failure handling identified. Ask which external subscriptions or credentials you must provide.

Agree acceptance criteria before approving the work. A useful criterion describes an observable result: a mobile visitor can submit an enquiry, the designated inbox receives it, and the website displays a clear confirmation. Keep testing away from real customers where it could create unwanted bookings, payments or messages.

Compare the delivery fee alongside hosting, licenses, maintenance and expected changes. A lower proposal may represent a smaller scope; a larger one should explain the additional work. Ask how changes are estimated and approved. Use the same first-year cost assumptions for every shortlisted supplier.

Ask for quality evidence beyond a performance score

Ask for the published URL, the test conditions and the customer journeys checked. A single PageSpeed score is a useful diagnostic, but it does not describe every visitor's experience. Google's Core Web Vitals guidance assesses loading, responsiveness and visual stability: good thresholds are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, evaluated at the 75th percentile of visits, separately for mobile and desktop.

Ask the team to distinguish lab tests from real-user measurements. A new or low-traffic site may not yet have enough public field data. In that case, agree launch checks and a later review when measurements are available. Test important inner pages and forms alongside the homepage; a fast opening screen can still lead to a frustrating task.

Accessibility also needs more than an automated score. W3C explains that tools cannot check every accessibility requirement and that human judgment is necessary. Ask for keyboard checks, visible focus, understandable form labels and errors, readable contrast and usable layouts when text is enlarged. Request a demonstration of the main journey without a mouse.

Security scope should match the website. For an application with accounts, permissions or sensitive data, ask what will be tested and which findings must be fixed before release. OWASP's Application Security Verification Standard provides a basis for specifying and verifying web application security requirements. Agree the relevant coverage instead of accepting an unexplained secure badge.

Keep business accounts and the exit path clear

Before work starts, decide who controls the domain registrar, hosting, CMS, analytics, Search Console and services used by the website. Keep business access and recovery details documented. Give collaborators the access they need through their own accounts where the service supports it, rather than sharing one administrator password everywhere.

Your domain deserves particular attention. ICANN recommends keeping registrar account information secure and recoverable, enabling multi-factor authentication when available and using registrar locks to help prevent unauthorized changes or transfers. Confirm who handles renewals and that the business can recover the account if a contact leaves.

Ask what you receive at handover: source files where included, content exports, design assets, deployment instructions, license details and training. Clarify which components belong to third-party platforms and which services require an ongoing subscription. Ask the supplier to explain what can be transferred, what can be exported and what would need rebuilding if you moved later.

You do not need to operate every technical service yourself. You do need a clear arrangement that lets your business continue operating when a supplier changes. Put access, handover and exit responsibilities into the written scope; do not assume that paying an invoice settles every ownership or licensing question.

Choose technology around the people who will use it

Ask who will update the site after launch and what they need to change. If your team publishes articles, adds products or revises service details weekly, ask to see those tasks in the proposed content management system. Have the person who will do the work try a representative edit during review.

A custom application, a managed website platform and a conventional CMS can each fit different requirements. The useful question is why a particular choice suits your content, integrations, budget and maintenance capacity. Ask which routine changes your team can make independently and which require development work.

Ask how the choice affects backups, exports, subscriptions and future developers. More technology does not automatically create a better business outcome. A clear explanation of the tradeoffs is a stronger signal than a long list of frameworks in a proposal.

Make SEO deliverables specific and question guarantees

Google's guidance on hiring an SEO recommends examining previous work, asking about success measures and checking references. It also warns against guarantees of first place. Treat a promise of instant rankings as a reason to ask harder questions, not as a benefit to add to a comparison sheet.

For a new business website, ask who defines the service pages and search topics, writes the content, checks crawl access, prepares titles and descriptions, and sets up measurement. For a replacement site, ask for an inventory of existing URLs and a redirect plan. Clarify whether ongoing content work and reporting are included or separately scoped.

An SEO-ready launch should come with specific checks and accountable owners. Search Console access and a sitemap help you inspect discovery; they do not purchase a ranking. Ask what the team will measure after launch and how it will distinguish visibility from useful enquiries. Apply the same scrutiny to claims about guaranteed AI citations.

Agree how delivery and support will work

Ask who leads the project and who will answer questions when implementation decisions arise. A timeline should identify milestones, client approvals, content deadlines and dependencies. Ask what happens if content arrives late or an external integration changes. The answer should make the schedule understandable, rather than treating the launch date as an unconditional promise.

Define the difference between correcting a defect, adding a feature and maintaining the website. Ask about the post-launch defect period, support hours, response expectations and fees for changes. A response time is the time to acknowledge or begin handling an issue; it is not necessarily a promise that every issue will be resolved within that period.

Identify who monitors important failures, maintains backups and handles renewals. Ask when a restore was last tested or how it will be tested for your project. Before launch, request a handover session and a short operating guide. You should leave knowing how to update content, find account details and report a problem with enough information to investigate it.

Compare proposals with an evidence-based scorecard

Once every company has answered the same brief, use a simple scorecard to organize the evidence. The weights below are our suggested starting point, not a research-validated ranking of agencies. Adjust them to your project before comparing suppliers. A transaction-heavy application may need more emphasis on engineering and security than a small editorial website.

Score each criterion from 0 to 5 using the proposal, a demonstration or a reference. Use the percentage weights as points: a score of 4 for a 20% criterion contributes 4 / 5 × 20 = 16 points. Add the contributions for a total out of 100. Mark missing information as unanswered and request it before scoring; uncertainty is not evidence of quality.

Keep essential requirements outside the total. If the business cannot control its domain, a required integration is excluded or nobody is responsible for the enquiry route, resolve that gap first. A high combined score should not hide a missing requirement. Compare prices only after the scope and assumptions are aligned.

Send every shortlisted company the same brief

Copy the outline below into your enquiry and replace the prompts with what you know. An honest constraint or unanswered question is useful. You do not need to specify every screen or choose the technology before the conversation begins.

• Our business and audience: describe what you offer, where you operate and who the website serves.
• The main result: describe the customer action the first release must support and the business handoff after it.
• Current website and content: include the URL, material you can supply and important pages or features to preserve.
• Essential scope: list required page types, editing needs, forms and integrations; separate later ideas.
• Budget and timing: give a working range, desired launch date and any fixed dependencies.
• Client responsibilities: identify who supplies content, reviews work and approves decisions.
• Please explain: your delivery role, milestones, acceptance checks, recurring costs, account access and support terms.

Choose the team whose answers you can verify

A useful shortlist ends with fewer unknowns. You understand what will be built, what your team must supply, how quality will be checked and what happens after launch. The right company for your business is the one that can support those answers with evidence and deliver within the agreed constraints.

If you are considering WebFreakz, start with our published work and bring this brief to a project conversation. We can discuss the customer journey, technical dependencies and a first release that stands on its own. Use the same questions to evaluate our proposal that you would use for any other supplier.