Ask for a scope model before a price
A website estimate describes a set of deliverables and assumptions. A page count alone is not a useful specification: ten pages sharing a layout can require less work than one configurator connected to a stock system.
Start with the decision the visitor must make. A villa website, for example, may need separate rental and purchase journeys. Those journeys require different content, enquiry fields and follow-up ownership even when they share a visual identity. Hillside’s public website and sales journey illustrate that distinction; they do not establish a standard budget for another project.
The parts of a useful estimate
| Work package | What to specify | What changes the effort |
|---|---|---|
| Discovery | Audiences, goals, sitemap, acceptance scenarios | Unresolved business rules |
| Content | Text, images, rights, translations, approvals | Missing source material |
| Design | Layouts, component states, responsive behaviour | Unique interactions and revisions |
| Engineering | Pages, CMS, forms, integrations | External APIs and permissions |
| Verification | Accessibility, browsers, SEO, data handling | Languages and critical workflows |
| Launch and ownership | Hosting, migration, training, maintenance | Existing data and operational needs |
Ask whether copywriting, translation review, asset licences, third-party subscriptions, taxes and ongoing support are included. Separate recurring provider fees from implementation. An estimate should state who provides access and what happens if an external service cannot support the promised workflow.
Compare proposals with the same acceptance scenario
Give each supplier a concrete scenario: a mobile visitor selects a villa, sends an enquiry once despite a connection retry, and the responsible person finds it in the CRM. Compare what each proposal includes to make that scenario work.
Use a base scope plus optional packages rather than an unexplained contingency. If a requirement is uncertain, commission a short discovery or integration proof first. Fix the budget for the validated scope after that investigation.
What to send for a first discussion
Provide your current URL, audiences, priority action, required languages, systems to connect, available content, launch constraints and decision maker. Ask for assumptions, exclusions, handover and acceptance criteria in writing. M48 can use that information to discuss website development without inventing a universal price.
A practical question
Can I compare quotes using price alone?
Compare the same deliverables, exclusions and acceptance journey first. A lower quote may leave content, integration recovery or handover outside the scope. Ask the supplier to identify those omissions before making a decision.