Start with the task, rather than the number of screens
A website introducing a company and a website collecting enquiries for complex equipment may have the same number of pages but require different work. The second may need a catalog, filters, specifications, documents and a handover of order parameters to a manager. These differences matter more than the page count itself.
Describe the main customer journey: the question they arrive with, what they should understand and the action they should take. List the team’s internal tasks separately — updating services, publishing projects and assigning enquiries. This helps distinguish launch essentials from features that can be added after demand is tested.
- Identify the main audience and the decision they make on the website.
- Choose the main conversion action: an enquiry, booking, calculation or purchase.
- Separate first-launch requirements from further development.
AI-generated illustration. An estimate starts with scenarios and scope boundaries. The project scope matters more than the overall number of screens.
What the estimate should show
An estimate should describe each stage’s deliverable. Research and structure produce a list of pages and user journeys; design produces agreed layouts and interface states; development produces working pages and features. Content population, migration, form testing and analytics setup also take time and should not be left implicit.
Ask for the number of unique templates and the terms for working with repeated pages. A hundred-item catalog usually does not mean a hundred separate designs, but each item still needs correct data. For integrations, record the system, exchange direction, update frequency and behavior when an error occurs.
- Structure, prototypes and responsive design.
- Development, forms and agreed integrations.
- Content preparation or migration with a specified volume.
- Testing, publication, training and bug-fixing terms.
Compare estimates with the same scope and deliverables; maintenance and service fees are estimated separately.
What most often changes the budget
Visual complexity and animation are not the only factors. Unprepared copy, inconsistent catalog data, multiple languages, migration of old URLs and approvals from several departments can substantially expand the work. An estimate based on a single reference therefore remains preliminary.
Clarify where a standard solution is sufficient and where a custom interface is needed. A familiar enquiry form and a complex order configurator, for example, solve different tasks and should not be priced as one element. For uncertain features, a separate design stage with a clear deliverable is useful; its result allows the development estimate to be refined.
How to compare studio proposals
Compare the same scope: pages, content readiness, mobile adaptation, integrations, analytics and support. A proposal with a lower total may exclude content population or migration of the old website. Ask for exclusions, recurring fees and the process for estimating additional tasks to be listed separately.
Clarify which materials and access credentials the company will retain: source code, design files, domain, hosting and service accounts. Also agree on acceptance criteria. “The form works” is more useful when it means a test enquiry is delivered with the correct fields and a clear error message.
- The same scope and measurable acceptance criteria.
- Approval procedures and changes to requirements.
- Handover of source files and access credentials.
- One-off costs separated from maintenance and service fees.
What to send for an initial estimate
A brief description of the business, a list of sections, two or three examples with explanations and a list of systems to integrate are enough for a substantive conversation. State which texts and photos are ready, who makes decisions and whether there is a mandatory launch date. See the service page for budget guidance; the final estimate depends on the agreed brief.
The ANTA case study shows a website with a multi-level catalog and enquiry processing. The Get Beauty case demonstrates a different format — presenting a brand and a product showcase. These examples help discuss the solution’s scope, but do not replace an assessment of your task.
