How to Choose a Web Developer for Your Small Business

Choose a web developer who can understand the job your website needs to do and turn it into a clear delivery plan. A strong candidate can show relevant work, explain decisions without hiding behind jargon, and put the scope, exclusions and post-launch responsibilities in writing.

Do not choose on portfolio or price alone. A polished website does not reveal which parts the developer delivered, and two similar totals may cover very different work. The useful comparison is between your requirements, the candidate's evidence, their working process and the agreement they offer.

Define the job before assessing developers

You do not need to produce a complete technical specification. You do need to explain the business task the website should support. That might be generating qualified enquiries, making appointments easier, selling products or giving existing customers access to information.

Prepare a short brief that covers the following.

• The people the website needs to serve
• The main action a visitor should be able to complete
• The content and assets already available
• The functions required for launch
• The ideas that can wait for a later version
• The person in your business who can make decisions and approve content
• Any firm budget or launch constraints

If the scope is still uncertain, the guide to what a small business website should include will help you separate essentials from features that can wait.

A developer can help shape the brief. Their proposal should then state the assumptions behind the price and schedule. Without those assumptions, an early estimate may look like a commitment even though important parts of the work remain unknown.

Choose the right kind of supplier first

Web developer is a broad label. Some developers focus on business websites built with a particular platform. Others specialise in ecommerce, integrations, customer portals or bespoke applications. A capable specialist can still be the wrong person for a project outside their area.

A standard website platform may be enough when the business needs a small set of stable pages, familiar forms and no unusual workflows. The sensible choice may then be a platform specialist or a do it yourself service. Custom development is easier to justify when a specific function, integration or workflow cannot be handled well by a template and established services.

Project shape also affects whether one person can deliver the work or several disciplines need to work in parallel. Read the comparison of a freelance web developer and a web agency if you need to choose the supplier model first.

Ask for evidence that resembles your project

Look for work with a relevant purpose or level of complexity. Experience in your industry can help, but it is not always essential. A developer who can explain a comparable booking journey, content-heavy website or integration may be more relevant than someone with many attractive home pages in your sector.

Ask each candidate to walk you through one or two projects and explain the following.

1. What the client needed to achieve
2. Which parts the candidate personally delivered
3. What constraints affected the work
4. Why the chosen approach fitted the problem
5. How the website was tested and handed over
6. What the candidate would do differently now

Ask for performance or business results only when the developer had access to the data and permission to share it. A claim about more enquiries or better visibility is not evidence by itself. An honest answer may be that the supplier built and tested the website while the client retained the business data.

Open the example websites on a phone and a computer. Try the navigation and core journeys, but do not submit test data through another company's forms. The site may also have changed since the original delivery, so use what you see to guide questions rather than treating it as a complete quality assessment.

Treat the first conversation as a sample of the work

A useful discovery conversation makes uncertainty visible. The developer should ask about customers, content, workflows, responsibilities and ongoing operation before presenting technology as the answer.

Ask every candidate the same core questions.

• What do you see as the main job of this website
• Which requirements should use standard features instead of custom development
• What information do you still need before the price and schedule are reliable
• Who will create, provide and approve the content
• How will we notice early if the project is moving in the wrong direction
• Who will do the work and will any part be subcontracted
• How will we communicate from discovery through launch

Do not judge answers by how technical they sound. Look for answers that are specific, understandable and connected to your project. A candidate who accepts every request without discussing consequences is not necessarily giving useful advice.

Compare like with like

Request a written proposal that separates the main parts of the work. A total price becomes comparable only when candidates are pricing the same delivery.

Check whether each proposal covers these areas.

• Discovery, site structure and design
• Page types and agreed functions
• Copy, images, translation and content entry
• Mobile layouts and relevant browsers
• Baseline technical SEO and metadata
• Accessibility goals and testing
• Forms, integrations and data migration
• Hosting, domain, licences and other recurring costs
• Review rounds and approvals
• Launch, training, documentation and handover
• Defect fixes, support and future changes

The guide to small business website costs explains how to compare first-year costs and identify differences between proposals.

A higher quote may be better value when it includes essential work omitted elsewhere. A lower quote may be exactly right for a genuinely smaller scope. Ask suppliers to make exclusions and optional costs visible so that you do not have to infer them.

Put responsibilities and change control in writing

The agreement should match the size of the project, but even a modest website needs clear boundaries. Record these points before work starts.

• Deliverables and explicit exclusions
• Milestones, client deadlines and dependencies
• Price, payment schedule and recurring charges
• How new requests and scope changes will be assessed and approved
• The licences, files and account access your business will receive
• Who handles defects, for how long and under what terms
• How either party can end the arrangement and what handover includes

If you also need to choose a billing model, the guide to fixed-price and hourly web development explains when stable scope or genuine unknowns make each approach more suitable.

Seek legal advice when ownership, data protection, liability or termination is important to the business. A developer can clarify the technical delivery, but that explanation is not a substitute for reviewing the contract.

Keep control of the domain and essential accounts

Your business should control its domain and the accounts needed to operate or move the website. A supplier can manage them day to day without being the only party able to sign in, renew a service or approve a transfer.

ICANN describes the registrant as the person or entity that enters into the registration agreement and manages the domain settings through the registrar. Check who the registrant is, how renewal works and who can transfer the domain. See ICANN's information for domain name registrants.

List the domain, hosting, source repository, content management system, analytics, Search Console, email services and any other third-party accounts. Agree who contracts with each service, who pays and what access the developer receives. Remove access that is no longer required when the work ends.

If a supplier processes personal data on your behalf in the EU or EEA, establish the parties' roles and the required contractual terms. The European Commission provides standard contractual clauses for controllers and processors under Article 28 of the GDPR. Obtain advice that reflects the services, countries and data involved in your project.

Turn quality into acceptance criteria

Fast, user-friendly and search-friendly are too broad to work as acceptance criteria. Describe the critical user journeys and the checks that will show whether they work.

A focused test plan might include these checks.

• The primary task can be completed on a typical phone and computer
• Navigation, links and forms are tested with realistic test data
• Errors and confirmations are understandable
• Core functions can be operated with a keyboard
• Important content remains readable at the agreed screen sizes
• Metadata, sharing and indexing are checked against the agreed SEO work
• Responsibility for defects and acceptance is assigned before launch

W3C recommends incorporating accessibility requirements into procurement and using acceptance testing for work delivered by an external supplier. Define the target, testing method and any exceptions instead of relying on a general promise that the site will be accessible. See W3C's guidance on planning web accessibility.

Be sceptical of SEO guarantees

A web developer can provide technical foundations such as a clear structure, useful metadata, mobile support and indexable pages. They cannot control a specific position in search results.

Google states that no one can guarantee a number one ranking and recommends asking suppliers to explain the changes they make and the reasoning behind them. Treat guaranteed positions, secret methods and undefined SEO packages as warning signs. See Google's advice on hiring SEO help.

Ask which technical and editorial tasks are included, who supplies the content and how the work will be checked. This separates a realistic scope from an outcome promise that the supplier cannot control.

Warning signs to investigate

One concern does not always disqualify a developer. Several unclear answers around important risks should slow the decision down.

• A fixed quote is offered for an unclear project without written assumptions
• Portfolio items are shown but the candidate cannot explain their own role
• The proposal does not identify who will carry out the work
• A platform is chosen without explaining its limits or how another supplier could take over
• The domain or essential accounts must remain solely in the supplier's name
• Recurring costs, licences or minimum terms are unclear
• Testing, defect handling and handover are absent from the proposal
• The supplier promises rankings, sales or other results without a defensible basis
• You are pressured to accept before material questions are answered

Proprietary technology is not automatically a poor choice. It may solve a standard requirement efficiently. You still need to know what can be exported, what changing supplier would involve and which costs or restrictions continue after launch.

A practical selection process

Use this sequence when you are ready to appoint someone.

1. Define the website's main job and essential scope
2. Shortlist candidates with evidence relevant to the purpose or complexity
3. Give them the same brief and ask the same core questions
4. Compare written proposals line by line
5. Resolve access, rights, testing, support and handover before signing
6. Check a relevant reference when the size or risk of the project warrants it
7. Choose the candidate with the most credible route to the agreed delivery

The final choice does not have to be the cheapest or the most technically ambitious. It should be the supplier whose skills and working model fit the project and whose agreement leaves the fewest important questions unanswered.