Leave with a clearer scope, a cost map, and questions that make proposals easier to compare.
Treat this as a planning aid, not a universal formula. The right decision still depends on the business, its audience, its existing systems, and the responsibilities agreed for the project.
Start with the job of the website
A budget cannot be useful until the website has a defined job. A brochure site, a lead-generation site, a catalogue, and a logged-in product have very different requirements even when they look similar from the outside.
Write one sentence that describes the outcome you need: explain a complex service, make a local business easier to contact, support sales conversations, publish a catalogue, validate a product idea, or replace an outdated website. This is more useful than beginning with a list of visual references.
Then list the decisions a visitor should be able to make. A website that only needs to encourage an enquiry has a different path from one that must let people compare plans, book a time, request a quote, browse products, or access an account.
- Who is the primary audience, and what do they need to understand first?
- What is the main action: enquiry, booking, quote request, product exploration, purchase, or something else?
- Which pages are essential for launch, rather than simply desirable later?
- What existing material can be reused, and what must be written, photographed, designed, or integrated?
Map the scope before asking for a price
A proposal is easier to trust when it states what is being designed and built. Ask for a page and feature map—not only a final number.
Content and structure
List the launch pages, their purpose, any location or service variations, and whether the content is ready. Content planning is part of scope because it affects hierarchy, layout, review, and migration.
Design and front end
Clarify whether the work includes a bespoke visual system, responsive layout, reusable components, interaction design, and accessibility-conscious implementation.
Functional requirements
Name every requirement that changes the build: forms, booking software, ecommerce, CRM or sheet handoff, maps, gated content, multilingual content, logins, data imports, or third-party APIs.
Launch and handoff
Confirm hosting, domain access, analytics, search setup, redirects, ownership, documentation, and who is responsible for production checks after deployment.
Separate the studio fee from ongoing costs
A website budget usually contains more than the initial design and build fee. Separating cost types early makes the commercial picture clearer and prevents a low initial figure from hiding a costly operating setup.
Not every project needs each category. The point is to make each one visible, identify who owns it, and distinguish a one-time cost from a recurring commitment. A good proposal can say what is excluded without making the project feel less considered.
- Strategy, content planning, design, development, testing, and project management.
- Photography, illustration, copywriting, translation, or specialist brand work where required.
- Domain registration, hosting, email, paid fonts, stock licences, plugins, CMS plans, booking software, payment services, or other third-party products.
- Migration, redirect mapping, data cleanup, and any work required to move away from an existing platform.
- Ongoing maintenance, content updates, campaign work, performance monitoring, or SEO work after the launch foundation is complete.
Compare proposals by assumptions, not by totals alone
Two proposals can have very different totals because they are solving different problems. The fairest comparison is a side-by-side view of scope, responsibilities, and exclusions.
- Does each proposal name the pages, templates, and design/development deliverables?
- Who provides or approves the copy, imagery, product data, legal content, and technical access?
- Are responsive behavior, accessibility, performance, and technical SEO foundations explicitly included?
- Which integrations are included, and which require separate discovery or vendor costs?
- How are review rounds, change requests, and timing handled?
- What is handed over at the end, and what depends on a third-party licence or account?
Create a brief someone can price responsibly
You do not need a long specification before speaking to a studio. You do need enough context for them to identify unknowns instead of guessing around them.
Share your business, audience, current URL if one exists, the launch goal, core pages, available content, brand material, known integrations, timeline constraints, and any platform restrictions. Include examples for tone or clarity, but describe why they are relevant rather than asking for a copy.
A focused brief creates a better first conversation. It gives both sides a chance to decide whether the project is a fit before turning a rough idea into a commitment.