Most website projects that run late or over budget don’t fail in development. They fail in planning, when goals stay vague, scope is never written down and content is “nearly ready” for three months. Planning a website project doesn’t need a project-management certificate. It needs a handful of clear decisions made in the right order. This guide walks through them: goals, audience and content, scope, choosing the right type of build, an honest budget, a realistic timeline, and the risks worth planning for before anyone writes a line of code.
Start with goals, not pages#
“We need a new website” is a starting point, not a goal. Before you discuss design or technology, write down what the site must achieve and how you’ll know whether it did. Good website goals are specific and measurable:
- Generate qualified enquiries through the contact form or booking tool.
- Sell products online and reduce manual order handling.
- Cut repetitive support emails by answering common questions clearly.
- Recruit staff, attract partners or support a funding round with credible information.
- Replace an old site that is slow, insecure or impossible to update.
For each goal, name a metric (form submissions, revenue, conversion rate, support volume) and record today’s baseline if you have one. Those metrics guide every later trade-off. If a feature doesn’t serve a goal, it’s a candidate for phase two. They also define “done” in a way everyone can agree on.
Identify the decision-makers#
Decide early who gives feedback and who approves. A project with one accountable decision-maker and a small group of named reviewers moves much faster than one where every stakeholder can reopen settled decisions. Write the names into the brief.
Audience, content and structure#
Who is the site for?#
List your main audiences and the top questions each one brings. A prospective customer, an existing customer looking for support and a job applicant need different paths through the site. Keep it practical: two or three primary audiences, each with the actions you want them to take. This is the groundwork for the UX decisions that move conversion rates.
Content inventory and sitemap#
If you have an existing site, list every page with its traffic and purpose, then decide for each: keep, rewrite, merge or delete. For a new site, draft a sitemap: the pages, their hierarchy and the main navigation. If you’re unsure how visitors expect information to be grouped, a quick card-sorting exercise with a few real users is cheap and often revealing.
Who writes the content?#
This is the most underestimated question in web projects. Decide who writes each page, who supplies photos and who approves the copy, and set dates for each. Design without real content tends to produce layouts that break when actual text arrives. We strongly recommend drafting at least your key pages (home, main services or products, about, contact) before design begins.
- Development rarely waits on code. It waits on copy, images, product data and approvals.
- Put content deadlines in the plan with the same weight as development milestones, and assign a named owner to each.
Define scope and prioritise ruthlessly#
Scope is the written list of what will be built: pages and templates, features, integrations and content migration. If it isn’t written down, it isn’t agreed. A useful way to keep scope honest is to sort every requirement into priority tiers, a method often called MoSCoW:
- Must have: the site can’t launch without it (contact form, core service pages, checkout for a store).
- Should have: important, but launch could happen without it if necessary (blog, newsletter integration).
- Could have: nice additions if time and budget allow (animated illustrations, a resource library).
- Won’t have (this time): explicitly parked for a later phase. Writing this list down prevents a lot of arguments.
Think in templates, not pages#
Cost and effort are driven far more by the number of unique templates and features than by the page count. Fifty service pages that share one well-designed template cost much less than ten pages that are each different. When you list scope, group pages by template: home, service, article, product, landing page, contact.
Don’t forget the non-functional requirements#
These rarely appear in a first brief, but they shape the build and are much cheaper to plan than to retrofit:
- Performance: set a performance budget for page weight, scripts and Core Web Vitals targets. web.dev’s performance budgets primer explains the idea.
- Accessibility: aim for WCAG 2.2 level AA. Our WCAG guide for small businesses covers what that means in practice.
- SEO and migration: URL structure, redirects from the old site and structured data. See the technical SEO launch checklist.
- Security and privacy: forms, user accounts, payment handling, cookie consent and data retention.
- Editing: who will update the site after launch, and how technical they are.
Choose the right type of build#
Most projects fall into one of four categories. Picking the right one early avoids paying for complexity you don’t need, or outgrowing a platform within a year. The prices below are our current fixed starting prices, listed so you have concrete reference points. Your final quote depends on scope.
| Build type | Best for | Typical scope | Our starting price |
|---|---|---|---|
| Landing page | A campaign, product launch or single service with one clear call to action | One long-form page, form or booking integration, analytics | $1,490 |
| WordPress website | Small and medium businesses that need a full site they can edit themselves | Several templates, blog, forms, SEO foundations, editor training | $3,900 |
| WooCommerce store | Selling physical or digital products, bookings or subscriptions | Catalogue, cart and checkout, payments, shipping and tax rules, order emails | $5,900 |
| Custom web application | Unique workflows: portals, dashboards, SaaS products, internal tools | User accounts, business logic, integrations and APIs, data model | from $9,500 |
A useful rule of thumb: if your requirements are mostly content, a CMS like WordPress is usually the right answer. If they are mostly workflow and data, so that users log in to do things rather than read things, you’re probably looking at a custom application, possibly alongside a marketing site.
Build an honest budget#
A realistic budget has three parts: the build, the running costs and a contingency. Leaving out either of the last two is the most common budgeting mistake we see.
1. The build#
Our packages above are typical starting points. What moves a quote up from there is predictable:
- More unique templates or complex layouts.
- Integrations with CRMs, booking systems, ERPs, payment providers or custom APIs.
- Content migration, especially large blogs or product catalogues with variations.
- Multilingual sites, user accounts and role-based permissions.
- Custom illustrations, photography, video or copywriting.
If you have a figure in mind, share it. A budget range lets a good studio propose the best solution within it, instead of guessing and quoting something unusable. Our pricing page has a project cost calculator for a first estimate.
2. Running costs#
| Item | Frequency | Notes |
|---|---|---|
| Domain name | Yearly | Renew automatically; register it in your own company’s account |
| Hosting | Monthly or yearly | Varies widely by type; compared in our hosting guide |
| Premium plugins, themes or SaaS tools | Usually yearly | Licences needed for updates and support |
| Maintenance and support | Monthly | Updates, backups, monitoring and fixes; our care plan is $149/month |
| Payment processing (stores) | Per transaction | Set by your payment provider |
| Content and marketing | Ongoing | New articles, campaigns, photography |
3. Contingency#
Every project discovers something: an integration with a quirky API, a content gap, a new legal requirement. We recommend holding back 10–20% of the build budget as contingency. It is a planning habit, not a prediction. If you don’t need it, it funds phase two.
Set a realistic timeline#
A website project moves through recognisable phases. Durations vary with scope and how quickly feedback arrives, so treat the ranges below as a rough guide for a typical small-business WordPress site, not a promise. Landing pages compress this considerably, and stores and custom applications extend it.
| Phase | What happens | Rough duration | Your main input |
|---|---|---|---|
| Discovery & planning | Goals, scope, sitemap, technical decisions | 1–2 weeks | Brief, workshops, decisions |
| Content & design | Wireframes, visual design, copy drafting | 2–3 weeks | Content, feedback rounds |
| Development | Templates, features, integrations, CMS setup | 2–4 weeks | Answering questions, supplying assets |
| Content entry & QA | Populating pages, testing on devices, accessibility and performance checks | 1–2 weeks | Reviewing and approving pages |
| Launch & handover | Go-live, redirects, analytics, editor training | A few days | Final sign-off |
Our process page explains how we run each phase. Two timeline tips matter more than any others:
- Work back from a real deadline, not a wished-for one. If you have a hard date such as a trade show, a product launch or the old hosting contract ending, say so on day one and let scope flex to meet it.
- Schedule feedback windows. Agree in advance how many review rounds each phase gets and how many days each round takes. Feedback that takes two weeks to arrive costs two weeks.
Write the brief#
Everything above fits into a short document that you can send to agencies or freelancers to get comparable quotes. One or two pages is enough. Here is a template you can copy:
# Website brief: [Company name]
## Goals & metrics
- Primary goal: ... (metric: ..., current baseline: ...)
- Secondary goals: ...
## Audiences
- Audience 1: who they are, top questions, key action
- Audience 2: ...
## Scope
- Templates/pages: home, service (x6), article, contact, ...
- Must have: ...
- Should have: ...
- Won't have (this phase): ...
- Integrations: CRM, booking, payments, newsletter ...
## Content
- Who writes copy: ... Photography: ... Deadline: ...
## Non-functional requirements
- Performance targets, WCAG 2.2 AA, SEO/redirects, editing needs
## Constraints
- Budget range: ... Hard deadline: ... Decision-maker: ...
## References
- Sites we like (and why): ...A brief like this tells a studio what you need and shows them you’ll be a well-organised client. That usually leads to sharper quotes and fewer surprises.
Compare quotes and choose a partner#
Send the same brief to each studio or freelancer you’re considering, so the quotes are comparable. Quotes can still differ a lot, and the cheapest figure isn’t always the cheapest project. When you compare them, look past the total:
What a good proposal shows#
- A restated understanding of your goals. A proposal that plays your brief back in its own words, and questions parts of it, shows the team has actually thought about your business.
- Clear inclusions and exclusions. Number of templates, design rounds, content entry, integrations, browser and device testing, accessibility and performance targets, and training. Ask what happens, and what it costs, when something falls outside them.
- Milestones and payment terms tied to deliverables rather than dates alone.
- Ownership and access. Confirmation that you will own the code, content, domain and accounts, with admin credentials handed over at launch.
- Post-launch support. A warranty period for defects, and a clear option for ongoing maintenance if you want it.
Questions worth asking#
- Who will actually work on the project, and who is my day-to-day contact?
- How do you handle change requests once the scope is agreed?
- Which plugins, frameworks or third-party services will the site depend on, and what do they cost each year?
- How will you test performance and accessibility before launch?
- Can I see live examples of similar work, and talk to you about the trade-offs in those projects?
Pay attention to how each candidate answers as well as what they say. A partner who explains trade-offs plainly, admits what they would not recommend and puts commitments in writing is usually the one who delivers on time. You can see examples of our approach in our portfolio.
Plan for risks and life after launch#
Common risks, and the cheap way to handle each#
- Scope creep: use a written change-request process that estimates cost and time before work starts, and keep a parking list for phase two.
- Lost SEO in a redesign: build the redirect map and keep URLs stable where possible.
- Vendor lock-in: make sure you own the domain, hosting account, code and content, and get admin access to everything.
- Single points of knowledge: get documentation and editor training as part of handover.
Plan the first 90 days after launch#
A launch is the start of a site’s working life. Budget time to review analytics against your goals, fix issues real users uncover and publish the content you parked. Plan who will handle updates, backups and security monitoring. For WordPress and WooCommerce sites, that maintenance isn’t optional, as our WordPress security hardening checklist explains.
- Define measurable goals and one accountable decision-maker before talking about design.
- Write scope down, prioritise with must/should/could/won’t, and think in templates rather than pages.
- Budget for the build, the running costs and a 10–20% contingency.
- Treat content and feedback deadlines as seriously as development milestones.
Turn your plan into a project#
A well-planned website project is calmer, cheaper and better than one that is figured out along the way. You don’t need every answer before you start. You do need clear goals, a written scope, an honest budget and a timeline that includes the people who supply content and feedback.
When you’re ready, try the project cost calculator on our pricing page, or look at our WordPress Website Development package if a full business site is what you need. Prefer to talk it through? Send us your brief, rough or polished, and we’ll help you shape it into a plan with a fixed price and a realistic timeline.
Frequently asked questions
How much should I budget for a new website?
It depends mostly on scope: the number of unique templates, content, integrations and whether you sell online. As a reference point, our fixed-price packages start at $1,490 for a landing page, $3,900 for a WordPress website and $5,900 for a WooCommerce store, with custom web applications from $9,500. Add ongoing costs for hosting, licences and maintenance, plus a contingency.
How long does it take to build a website?
A focused landing page can often be delivered within a few weeks, a typical small-business WordPress site in roughly one to two months and an online store or custom application in longer, phased timelines. The biggest variable is usually not development but how quickly content and feedback arrive.
What should a website brief include?
Goals and how you'll measure them, target audiences, a list of pages or a draft sitemap, required features and integrations, content responsibilities, brand assets, examples of sites you like and why, budget range, deadline and who signs off decisions. A one- or two-page brief is enough to get accurate quotes.
What is scope creep and how do I avoid it?
Scope creep is the gradual addition of features or changes after the plan is agreed, which pushes out both budget and timeline. Prevent it with a written scope, a prioritised feature list, a change-request process that estimates cost and time before work starts, and a parking list for ideas that can wait for phase two.
