Choose a website developer based on verified experience, a clear scope, acceptance criteria and terms for future work. Price comparisons become useful when contractors estimate the same pages, features, materials and integrations.
Two proposals described as a “turnkey corporate website” may produce different outcomes. One includes structure, copy, content population and enquiry processing. Another assembles pages using the customer’s prepared materials. To choose a web studio or independent developer, first make these differences explicit.
Below is a practical comparison process, from a short brief to demonstrating the finished website. The questions and table can be used with any contractor.
1. Describe the task every candidate should estimate
Start with customer and team actions. For example, a company sells equipment: a visitor finds a suitable model, attaches a connection diagram and sends a request. A manager receives the enquiry with the product name and attachment, replies to the customer and changes its status. This is a hypothetical example for comparing proposals, not the result of a specific project.
For such a task, “a catalog and a form” leaves many questions. Who imports products? Can parameters be selected? Where is the enquiry stored? What does the customer see if a file upload fails? Is a CRM connection needed?
Prepare one document for all candidates:
- Goal: the visitor action and team outcome the business needs.
- Structure: proposed sections, page types and main user journeys.
- Materials: available text, photos and data, and who prepares what is missing.
- Connected systems: CRM, business management software, payment, delivery and other real dependencies.
- Constraints: the required launch date, employee availability, budget guidance and mandatory first-version features.
- Checking the outcome: what you want to perform yourself during the demonstration.
You do not need to know the technical solution in advance. Identify unknowns, such as a catalog export format that still needs investigation. The contractor can then propose discovery or a prototype as a separate stage and explain what will allow the estimate to be refined.
For detailed preparation, see “How to prepare a website brief”.
2. Bring proposals to a common scope
Ask each candidate to complete the same list. Every row needs a deliverable, an owner, a verification method and a status: “included,” “separate estimate” or “not required.”
| What to compare | Which outcome to clarify | What to ask the contractor |
|---|---|---|
Structure and prototype | A section map and main user journeys | Which pages and states are included? |
Design | Layouts for the agreed page types | How is the site checked on mobile, and what happens with long text and errors? |
Content | Text, images and populated records | Who prepares and uploads materials, and what volume is included? |
Management | An editor working with real records | What can an employee change independently? |
Enquiries and integrations | An enquiry reaches the agreed system | Where is it stored, and how is a transfer failure visible? |
Search foundations | Accessible pages and agreed metadata | Are old URLs migrated, and who checks indexing settings? |
Launch and handover | A working site and access credentials | Who publishes the site, trains the editor and provides instructions? |
Operation | A clear process for updates and support requests | What is paid regularly, and who is responsible after launch? |
Pay particular attention to “up to,” “from” and “provided ready materials are available.” These are not inherently problems: they may reflect reasonable boundaries. Ask which scope and conditions the estimate applies to.
Compare one-off development and recurring costs separately: the platform, hosting, external services and support. Keep an unknown integration as its own line with a process for clarification. A total based on several unverified assumptions is not yet a comparable final estimate.
Clarify the pricing model: a fixed price for an agreed scope, or payment for actual hours. In the latter case, ask about rates, work reports and a budget limit. For both models, record payment stages and prior approval of additional expenses. A fixed-scope proposal and an open hourly budget require different oversight.
For more on cost components, see “How much a corporate website costs and what an estimate includes”.
3. Check the journey you need in the portfolio
Ask to see a published project, hear the team’s role and walk through an action similar to your task. For a showcase, that might be product selection and proceeding to purchase. For a service website, finding a service and sending an enquiry. For a platform, a user’s work after signing in.
The delivered scope matters: the contractor may have created only the design, one integration or the entire product. Where access is restricted, discuss an agreed demonstration or anonymized scenario; lack of access to every internal screen proves nothing by itself.
These differences can be seen in specific examples from DDRW’s published portfolio:
- Get Beauty: the case study describes a cosmetics brand showcase with “Buy” links to Wildberries. For a similar project, establish whether it needs its own checkout or a redirect to an external platform.
- ANTA: the case describes a service catalog and an enquiry with a task description and attachment. For a similar site, service structure, enquiry context and file handling are estimated separately.
- Meetki: the case covers a connected cycle of meetings, outcomes and next actions. For this kind of platform, discuss states, roles and record relationships that a single homepage cannot show.
These examples help compare product structure and task scope. They do not justify promising the same budget, sales growth or timeline for a different project.
If a candidate cites commercial results, ask about the period, data source and the team’s own contribution. A number without methodology does not show what happened because of website development.
4. Ask the developer 12 questions before choosing
Keep the answers in one document alongside the estimate. A useful answer contains an example, deliverable or process you can check.
- How do you understand our task? Ask for a description of the customer journey and the employee’s work after an enquiry.
- What is included in the first version? Clarify pages, features, states and what is deliberately postponed.
- Which assumptions underlie the estimate? Find out which data, access credentials and decisions the customer must provide.
- What exactly did you do in a similar project? Ask to see the corresponding work.
- Who makes decisions and manages the project? The owner, communication channel and approval process should be clear.
- What do intermediate results look like? Establish when you can see the structure, prototype and working journey.
- Who prepares content? Separate copywriting, photo selection, processing and uploads.
- How will an employee manage the website? Ask to see a service, image or product changed in the editor.
- How are integrations and errors tested? Discuss external-service failure, repeated requests and incomplete data.
- How are scope changes approved? Understand when scope, timeline and cost are recalculated.
- What is handed over at completion? List credentials, materials, instructions and available data-export methods.
- What happens after launch? Establish where to report issues, support hours and the boundary between fixes and new work.
A technical term alone does not answer a quality question. Ask how the chosen solution relates to your task and how the team can maintain it. The GOV.UK introduction to choosing technology considers total cost of ownership, control of data and the ability to change the solution as needs develop among the important factors.
5. Connect each stage to a verifiable result
Before starting, agree on what will be shown at each stage and who decides on the customer’s side. “Design is ready” becomes clearer when you know which page types and states are approved. “The form works” requires following an enquiry to where an employee handles it.
Agree on a short verification journey for the working site:
Open a service page on mobile → complete an enquiry with an attachment → see confirmation → find the enquiry in the agreed interface → check the saved service context and file.
Also test an input error, a repeated click and temporary unavailability of a connected system. The required set depends on the project; agree on it in advance so acceptance does not become an endless addition of new requirements.
Speed also needs measurement conditions: the pages, device, network and tool used. Google Web Vitals covers loading, responsiveness and visual stability through LCP, INP and CLS. Ask the contractor to distinguish lab checks from real-visit data; a score without conditions is difficult to use for acceptance.
Check field labels, visible keyboard focus, readability and operation with enlarged text. W3C WAI preliminary checks help start an accessibility evaluation, but do not replace a full review.
A stage should produce an accessible demonstration, an agreed issue list and a clear decision on the next step. The checks can be supplemented with the website acceptance checklist.
6. Check website management and handover materials
Ask to see the admin interface before the project ends. Choose an ordinary task: replacing a photo, adding a service, correcting text or viewing a new enquiry. Let the future editor perform it using the instructions. This demonstration is more useful than a CMS feature list.
List what the team should control after launch:
- Domain and infrastructure: where management accounts are held, and who controls payments and access recovery.
- Website and materials: which designs, files, customization source code and instructions are handed over.
- Data: how to export content and enquiries, what backups include and how restoration is provided for.
- Analytics and external services: who owns working accounts and grants staff access.
- Support: the owner, contact channel, update process and further changes.
Clarify the chosen platform’s specifics separately. Editing pages, exporting data and moving the website to another environment are different capabilities. Do not assume editor access automatically provides the others.
Give employees individual access with the necessary permissions. Transfer passwords and private keys through a secure method; keep the account inventory separate from the secrets themselves. Additional operating questions are covered in our article on website support after launch.
7. Decide using facts and open questions
Before choosing, mark what is confirmed and what still needs checking. You should have a comparable scope, a relevant work example, clear stages, acceptance criteria and a handover package.
Reasons for further discussion include the same estimate for every task without questions, a portfolio without an explanation of involvement, demonstrations withheld until completion, or no answer about recurring costs. Ask for specifics. The substance of the response will clarify whether you can proceed.
Treat guarantees of a first-place search ranking separately from development. Google Search Central’s guidance on choosing an SEO specialist recommends checking previous work and being cautious about first-position guarantees. A website project should record specific technical work, content and a method for later evaluation.
If much of the task remains unknown, start with a limited stage: discovery, structure or a prototype of the required journey. Define that stage’s deliverable and handover too. It helps clarify further development; a commitment to continue the whole project with the same team must not be silently implied.
A request template for comparing proposals
We need a website for [company and audience]. The main journey is [customer action and employee outcome]. The first version includes [sections and features]. We already have [materials and data]. We need to clarify [integrations and constraints]. Please describe the scope, assumptions, stages, acceptance criteria, handover package and recurring costs separately. Show a similar journey in a completed project and explain your team’s role.
Frequently asked questions
Should we choose a web studio or an independent developer?
Compare task coverage, responsibility and ongoing support. A narrow task may suit one specialist. A project involving research, design, content and integrations requires coordinated work across several competencies. Establish who will actually do each part and who can replace the main person.
Should we choose the contractor with the most detailed estimate?
The number of lines is not a criterion by itself. It matters more whether each line connects to a result and verification method. A detailed estimate with undefined volumes still leaves substantial questions.
Can proposals be compared before a full specification is prepared?
Yes, for preliminary selection. Provide the same task description, list unknowns and ask for the estimate’s boundaries. The final scope and commitments are refined as the work is explored; compare preliminary ranges together with their assumptions.
Must the website move to a new CMS?
First establish what limits the existing system: editing, a required journey, integration or maintenance. Ask for a comparison of customization and migration, accounting for data, URLs and team training. The CMS name alone does not explain which problem will be solved.
Discuss website development with DDRW
Send a task description, your current website and main journeys. We will review the first version’s scope and questions about materials and integrations, then propose the next step for an estimate.
For a public website, start with “Business websites”; for a system with roles and connected processes, start with web platforms and customer portals. Contact DDRW.
