The starting point
Compare the same scope, ownership, and ongoing responsibilities before comparing the price.
Start with the job your website needs to do
A five-page business website and a booking platform are different projects, even if both are called a website. A business site helps visitors understand your offer and enquire. A web application may also handle accounts, payments, schedules, permissions, and customer data.
Write down the primary visitor, their next action, and the features that support it. For a training institute, that might be browsing courses and submitting an enquiry. Student accounts and online lessons belong in a separate scope unless they are essential for launch.
The decisions that change the quote
Page count matters, but unique layouts and behaviour usually tell you more about the work. Ten pages using one agreed layout can require less design effort than three pages with custom interactive features.
Content is another responsibility to settle early. If a developer is expected to write copy, edit photographs, move existing articles, or create illustrations, the proposal should say so. Multilingual content also needs translation, navigation, and review.
- Number of unique page layouts and reusable templates
- Custom design versus adapting an existing theme
- Who supplies and approves text, images, and translations
- Forms, payments, booking systems, and other integrations
- Content editing, data migration, and administrator access
- Accessibility, device testing, and technical SEO requirements
Separate the build from ongoing expenses
Domain registration, hosting, email, paid plugins, payment processing, and third-party services may create recurring costs. Ask whose accounts hold these services, who pays renewals, and what happens if the provider's pricing changes.
Maintenance should have a defined scope. Content edits, dependency updates, backups, incident response, and new features are different kinds of work. A support agreement should explain what is included and how additional requests are estimated.
Ask for a comparable written proposal
BuildNerd quotes after understanding the pages, features, content, and delivery requirements. We do not publish a universal starting price because a useful estimate depends on that scope. Request a breakdown of the initial build, ongoing services, and optional work.
A cheaper proposal may exclude work you assumed was included. Ask each provider to state deliverables, revisions, acceptance criteria, milestones, ownership terms, and handover documentation. Compare those answers before choosing.
- What exactly will be ready at launch?
- Which fees recur, and who owns the service accounts?
- What is excluded from this estimate?
- How are changes to the agreed scope handled?
- What testing and post-launch support are included?
Prepare a brief for a useful estimate
Send your business description, intended users, required pages, reference sites, existing assets, integrations, target launch window, and budget range. Mark each feature as essential or later. This helps a developer propose an achievable first release rather than guess at your expectations.
If requirements are still unclear, start with a smaller discovery exercise. Its output should be a feature list, user journeys, assumptions, and a delivery plan you can use to evaluate the next investment.
Turn the brief into a conversation.
Tell us about your users, required platforms, and what the first release needs to do.
Discuss your project