How to choose a website development contractor: criteria and questions to ask
Choose a website contractor using the same brief and measurable deliverables for every candidate. Ask several teams to estimate the same page structure, features, and integrations. Then compare what each quote includes: discovery, design, content, data migration, testing, and post-launch support.
This approach suits a business commissioning a corporate website, catalogue or online shop. A small landing page may need fewer checks. A client portal, 1C or CRM integration, multiple languages and existing search traffic require more detailed planning.
Short answer: start with the same brief for every candidate. Before signing a contract, request the scope, acceptance criteria, access and ownership arrangements, launch plan and support boundaries. These documents provide a common basis for comparison.
What to prepare before requesting a price
Quotes will not be comparable if one team receives only a request for a modern website and another receives detailed pages and integrations. First record:
- The website's purpose and the visitor's main action: an enquiry, purchase, booking or quotation request.
- Page types: home, services, categories, product pages, case studies, articles and utility pages.
- Content sources and the person responsible for copy, photos, specifications and translation.
- Integrations: CRM, stock management, payments, analytics, telephony and email services. Specify each system and exchange direction.
- Required constraints: deadlines, languages, accessibility, staff roles and data location.
- The existing website and URLs to retain or migrate.
For a corporate project, use the technical specification template. It helps separate the required scope of the first version from the features that can be added later.
How to review a contractor's portfolio and team
A portfolio shows the result but not the contractor's contribution. Ask about two or three similar projects: what the team built, which integrations it implemented and who maintains the website. Open the projects on your phone and check navigation, forms, loading and key pages.
Ask who will manage daily work and identify the roles: project manager, developer, designer, editor and SEO specialist. Presentation slides do not establish responsibilities. If work is subcontracted, agree on who remains accountable to you.
| What to ask | What the answer should establish |
|---|---|
| Can you show a project with a similar catalogue, portal or integration? | A working project and an explanation of the team's contribution |
| Who approves the structure and prototypes? | Named owners on the client's and contractor's sides |
| Where can we review work in progress? | A test environment and a demonstration process |
| How are scope changes recorded? | A process for estimating and approving costs and timing |
| Who fixes bugs after launch? | Response expectations, warranty scope and the support channel |
Client confidentiality may prevent a public case study. Ask for an anonymised description, permitted screen demonstrations or a technical discussion that does not disclose another client's data.
How to compare estimates if the amounts differ
For a detailed review, use the website quote comparison checklist, which separates content, integrations, acceptance and recurring costs.
Divide each proposal into the same work areas. If one includes content and testing while another leaves them to the client, their totals cover different scopes.
| Block | What the estimate should specify |
|---|---|
| Planning | Page map, user journeys, prototypes and requirements |
| Design | Unique templates, responsive states and approval process |
| Development | Functions, integrations, administration, user roles and test environment |
| Content and migration | Who prepares and uploads content, and which URLs and data are migrated |
| Testing and launch | Test scenarios, defect fixes, analytics setup and cutover plan |
| Support | Included post-launch work, additional charges and response expectations |
Ask about assumptions such as a limit on page types, one CRM or client-supplied content. Request a revised estimate for assumptions that do not match your project. Compare hosting, licences, paid extensions, backups and support separately. For the overall scope, see the cost of a corporate website.
Which ownership and access arrangements should you agree before work starts?
Review the contract and appendices with a lawyer: ownership of the domain, hosting account, repository, design files, copy and custom code; third-party licences; and acceptance deliverables. List the technical handover separately: source code, startup instructions, accounts, analytics access, a backup and external services.
The client should retain their own administrative access to the domain and essential services. Give the contractor a separate account with the permissions needed for the work. This makes handover and recovery easier when the engagement ends.
What to ask about SEO before development
Search accessibility depends on the site's structure and implementation. Ask where the work plan covers URLs, page titles, internal links, sitemap, canonical tags, migration redirects and indexing checks after launch. If addresses change, request a mapping of old URLs to new ones.
Google recommends standard links <a href> to discover pages and descriptive link text. Its page title guidelines recommend descriptive, concise titles. Ask for page-template examples and links to important content to clarify the proposed SEO work.
A contractor cannot guarantee a particular ranking or stable traffic after launch. Agree on testable implementation requirements and the process for fixing defects.
How to accept the website and retain control after launch
Agree on acceptance through user actions: submit a form, place an order, find a page, sign in, test CRM exchange and use the site on a phone. Define the expected result of each check. Record defects with the URL, steps to reproduce them and priority.
Before switching to the new site, obtain a backup and rollback plan. After launch, check key URLs, forms, analytics events, sitemap and server responses. For an existing site with traffic, use the corporate website migration plan.
How to hand over an existing website to a new contractor
When choosing a team for an existing website, include a separate handover phase in the proposals you compare. Receiving an archive and hosting access does not demonstrate that the new team can restore the site, deploy changes and maintain integrations. Agree on the handover deliverables before the previous contractor finishes their work.
The handover template at the start of this article helps you list systems and checks. For each item, record the account owner, technical contact, renewal date and an evidence reference. Keep passwords, tokens, enquiry contents and personal data out of the shared spreadsheet. Agree separately on account identification and secure access.
| What to hand over | What the new team should verify |
|---|---|
| Domain, DNS and certificate | The client controls the account; DNS records, renewal dates and the certificate renewal process are documented |
| Hosting and infrastructure | Hosting, required services and owners are identified; access permits the agreed tasks |
| Source code and startup instructions | The deployed version is identified; a copy can be built and run in a separate environment |
| Database, uploaded files and backups | The agreed backup can be restored; its date and subsequent data changes are identified |
| CMS, design files and licences | An editor can update content; component usage and renewal terms are understood |
| Forms and integrations | A test enquiry reached the agreed recipient; exchanges with external systems have been checked |
| Analytics and search tools | The client retains control; analytics identifiers, properties and owners are documented |
| Deployment and support | Deployment, rollback conditions, the support channel and outstanding defects are documented |
A WordPress backup needs both files and the database: these are separate parts of the site. The official WordPress guide covers them separately. A file archive without the database does not demonstrate that the complete site can be restored.
How to verify the handover
- List systems, owners and renewal dates. Mark missing access and documentation as unverified.
- Prepare the agreed backup. The new team restores it in a separate environment; live email campaigns, payments and enquiry delivery from the test copy must be disabled or directed to test systems.
- Check content editing, selected pages, forms and integrations. Record the steps, expected outcome and evidence of the check.
- Deploy an agreed small change in the test environment and verify rollback to the previous version. Being able to open the site does not establish that deployment works.
- Agree on when responsibility transfers and how to carry over the latest changes. For a site handling orders or enquiries, account separately for data created after the backup.
- After acceptance, review the previous team's access: disable accounts that are no longer needed and rotate shared secrets where they were used. Check that the new settings have not disrupted the site or integrations.
Keep a list of exceptions. An inaccessible service, missing licence, untested import or known defect must not be marked as handed over without evidence. Assign an owner and next action to each issue. The parties agree on acceptance terms and timing; this technical checklist does not replace those agreements.
If the team change also involves a different CMS, hosting provider or URL structure, use the website migration plan. When handing over maintenance without that migration, the main deliverable is the new team's ability to maintain and deploy the existing project.
Checklist for shortlisted contractors
- Every team received the same brief and stated its estimate assumptions.
- Proposals identify stages, deliverables and owners.
- A relevant working project and the contractor's contribution were demonstrated.
- Client-supplied materials and access are listed.
- Ownership of code, domain, design files and content is agreed.
- Testing, acceptance, launch and defect handling are defined.
- Licence, hosting and support costs are listed.
- The existing website has a plan for retaining and migrating URLs.
If two comparable proposals remain, discuss one difficult project scenario with each team. A specific constraint provides a better basis for the decision than a general technology presentation. For an independent review of the brief and risks, consider IT consultation.
Development of a complex web project
From idea to scalable code. Leave a request for a preliminary assessment of your project (budget and deadlines).
FAQ
Are a website archive and hosting access enough?
Ask the new team to restore the agreed backup and demonstrate deploying a change in a separate environment. You also need source code, the database, uploaded files, external service settings and startup instructions appropriate to your project.
When should the previous contractor's access be removed?
Agree on when work ends and responsibility transfers. After confirmed acceptance, review unnecessary access and shared secrets. A security incident requires a separate decision about restricting access; a routine handover should not leave the site without a team in control.
Does changing developers require changing the platform?
Changing teams does not itself require replacing the CMS or framework. First verify that the existing project can be maintained, deployed and restored. Assess migration separately if platform limitations or new requirements have been confirmed.