How to Hire a Web Developer in 2026: A Complete Vetting Checklist

Hire a web developer who can explain a relevant implementation, demonstrate the work, and leave you with a maintainable site. Define the customer tasks and acceptance checks first, then compare each candidate’s approach to meeting them.

The checklist below is designed for a small business commissioning a website, migration, or web application. It combines a practical interview, a bounded paid assessment where useful, and specific launch checks. Adapt the scope to your project rather than making every candidate complete an unnecessarily large test.

1. Describe the site before choosing a stack

Start with users and actions. Will visitors read service pages, book appointments, buy products, or sign into an account? Who will edit content? Which systems must exchange data? Document the existing hosting, domain registration, content, integrations, and any contractual constraints.

Then ask candidates to explain their proposed implementation. A content site with occasional updates may suit a managed CMS or a simple static site. A customer portal needs a more detailed account, permissions, and data design. A specific programming language is a requirement when it fits the system you must maintain, not merely because it appears in a trend list.

For an existing website, request an assessment before approving a rebuild. Ask which problems require replacement and which can be fixed in place. Include the cost of content migration, redirects, staff training, and ongoing subscriptions in that decision.

2. Review one relevant project in depth

Ask the candidate to walk through a project comparable to yours. Identify the original brief, their personal contribution, constraints, and responsibilities after launch. A shared team portfolio is useful when ownership of the work is clear.

Open a live example if available and follow a real customer journey: find a service, navigate on a phone, and reach the contact step. Do not submit real orders or send test inquiries to someone else’s business without permission. A staging demonstration or recorded walkthrough can be appropriate when client work is confidential.

Ask what changed after handoff: images, plugins, content, or hosting may have been updated. Request an explanation of the candidate’s original contribution and any measurements from that stage so you can assess the work in context.

3. Interpret performance and accessibility evidence correctly

Google’s Core Web Vitals guidance covers loading, responsiveness, and visual stability. Good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1. Ask which pages will be measured and how those measures fit the project’s performance plan.

Specify representative pages, mobile and desktop conditions, and whether results come from real users or a controlled test. Ask which dependencies the developer can change and document third-party or hosting constraints in the scope.

Use W3C Easy Checks for an initial review of headings, text alternatives, keyboard access, focus, form labels, and errors. A comprehensive assessment needs a wider scope. Agree on the required standard, manual and automated review methods, and responsibility for correcting issues.

4. Review an Authorized Code Sample

If code review is relevant, ask for a sample the candidate is authorized to share. Request a short explanation of its structure, a difficult tradeoff, and how another developer would run it. Someone maintaining proprietary software may have little public code.

GitHub’s documentation explains that public contribution graphs show public repository activity by default, while private activity has separate visibility controls. For proprietary work, request an authorized walkthrough or a small sample project.

Evaluate readable changes, sensible error handling, reproducible setup, and tests suited to the project. If you cannot assess those features yourself, budget for an independent technical reviewer. Counting commits or rewarding a large number of files does not substitute for that judgment.

5. Agree on a small paid assessment when uncertainty remains

Use a task that resembles the real work without requiring candidates to build your whole product. One example is fixing a documented form-validation bug in a sample application. Provide a sanitized repository, expected behavior, and the permitted tools. Agree on payment, time allowance, and ownership before work starts.

Put an effort limit and fee in the assessment agreement. If the issue needs further investigation, ask for findings and a revised estimate. Review what was learned before authorizing more work, just as you would on the full project.

Review the result against a short rubric: can the problem be reproduced, does the fix address it, are important error paths considered, and can another person understand the change? Ask the candidate to explain any AI-assisted work and how they verified it. Tool use is less informative than the ability to reason about and maintain the result.

6. Turn security promises into requirements

Identify the data the site will hold and the actions each user role can take. Ask how permissions, account recovery, software updates, backups, and logs will be handled. Give the developer access appropriate to the task through individual accounts, with stronger authentication available on the relevant services.

The OWASP Application Security Verification Standard provides application-security requirements that can be used in procurement contracts. Have a qualified reviewer select the relevant requirements, identify the evidence to collect, and agree how defects will be corrected before launch.

Keep production secrets out of interview materials and sample repositories. Use test credentials and sanitized data for assessment. For launch, record who controls recovery methods, which credentials must be transferred or rotated, and who responds if a dependency needs an urgent fix.

7. Price the full engagement and its dependencies

Request a proposal separating discovery, design, implementation, migration, verification, deployment, and maintenance. State who supplies copy, images, product data, and legal text. A project can stall even when the developer is available if those inputs are missing.

For a fixed-price arrangement, define milestones by usable outputs rather than percentages of time elapsed. For hourly work, agree on a cap and an approval process for exceeding it. Funding a platform milestone is different from releasing payment to the freelancer; use the actual contract’s payment process.

Ask how new requests are priced. Changing one approved page layout is different from introducing a customer account system. Preserve the original scope and record approved changes so the final invoice can be explained.

8. Make launch and handoff reviewable

Use a checklist with named owners and evidence. For example:

Area	Example acceptance check
Contact flow	Approved test reaches the intended recipient and shows a useful confirmation
Content	Agreed pages, images, navigation, and metadata are present
Migration	Important old URLs resolve to the intended new destinations
Access	Business owner controls domain, hosting, repository, and recovery settings
Recovery	Backup and restoration instructions are documented and demonstrated as agreed
Maintenance	Update responsibility, support period, exclusions, and rates are recorded

Run the agreed checks in staging and repeat essential customer journeys after deployment. Keep a list of known issues with severity and ownership. Collect source files, setup instructions, licenses, and recurring subscription details before closing the engagement.

Our project brief guide can organize these requirements into a proposal request. The objective is to hire someone whose decisions and deliverables you can evaluate, then leave your business with a site it can continue to operate.