The short version: plan a build in this order - goals, then content and scope, then stack, then timeline and budget. Jumping straight to "which platform should we use?" is the most common and most expensive mistake in a website project, because the platform is a consequence of the first three decisions, not a starting point. Pin down what the site is for and what it must contain, draw a hard line around version 1, and the right stack and a realistic schedule mostly pick themselves. Get the order wrong and you pay for it in rework.
Why the platform is the wrong first question
Almost every stalled or over-budget build I have seen started the same way: someone chose the technology before anyone had agreed what the site was for or what would go on it. After that the content, the scope and the deadline all get bent to fit a decision made blind.
The platform is downstream. A brochure site for a law firm, a content-heavy publication, and a booking product that takes payments are three different builds that might all be described as "a website." What they need diverges the moment you look at goals and content. So plan in this order, and do not skip a step:
- Goal - what the site must accomplish, and the single most important action a visitor takes.
- Content and pages - what actually has to exist, written and gathered before design.
- Scope - what is in version 1 and what is explicitly out.
- Stack - chosen to fit 1 to 3, not the other way round.
- Timeline and budget - phased against real scope, not a wished-for launch date.
What is the one primary action on this site?
Write one sentence: "This site succeeds when a visitor _______." Books a call. Buys the plan. Reads and subscribes. Submits a qualified enquiry. One primary action per site, or at most one per major template.
This forces priority. If everything is important, nothing is, and you end up with a homepage that asks the visitor to do nine things and gets them to do none. The primary action drives layout, navigation, what goes above the fold, and what you measure after launch. Secondary goals are fine, but name them as secondary in writing so they do not quietly compete for the same space.
If the people paying for the site cannot agree on one primary action, stop. That disagreement is the real project risk, and it is far cheaper to resolve in a document than in a third round of design revisions.
Why you inventory content before you design
Content-first is the step that keeps projects on schedule. Design is the shape that content takes. If the words, images, product data and legal pages do not exist when design starts, the designer invents placeholder shapes, and every one of those shapes gets reworked when the real content arrives longer, shorter or missing entirely.
Before design begins, build a page inventory - a plain list of every page and what lives on it:
- Every page and template the site needs (home, about, service or product pages, contact, legal, blog or resource index, and so on).
- Who owns the copy for each, and whether it exists, needs editing, or needs writing from scratch.
- What media each page needs: photography, logos, diagrams, video, downloadable files.
- Any data feeding the site: a product catalogue, listings, team bios, case content.
Late content is the leading cause of a slipped launch, and it is almost always the client side that is late, not the build side. Knowing that up front lets you start writing early instead of discovering the gap in week six.
How do I decide what goes in version 1?
Scope is two columns: in v1 and explicitly out of v1. The second column saves the project. Writing down what you are deliberately not building yet protects a budget more than any other single habit, because "out of v1" is a decision, whereas silence is an invitation for the feature to reappear mid-build as an assumption.
Good candidates to push out of v1: multi-language versions, gated member areas, complex search and filtering, a customer portal, an events system, e-commerce when the business is not yet selling online. None of these are wrong to want. They are wrong to fund before the core site proves it works. Ship the smaller thing, learn from real visitors, then add.
A useful test for each feature: does the site fail at its primary action without this? If no, it is a v2 candidate. Be honest, and get the "out" list signed off by the same people who signed off the goal.
How do I choose the stack for the job?
Once the goal, content and scope are settled, the stack conversation gets short and factual. You are matching the job to the tool, not picking a favourite.
- A non-technical team that must publish and edit daily without a developer points toward an editor-first CMS.
- A site where speed, custom functionality and technical control matter most points toward a modern framework front end you can tune.
- When editors and developers both need to work on the same structured content, a headless CMS paired with a Next.js or Astro front end is usually the answer.
There is no universally "best" stack - the right choice depends on who edits the site, how it renders, and what it has to do. Rather than re-argue every option here, see the technologies we build on for how each one earns its place, plus the deeper CMS-choice and framework-choice guides in this Resources section. At the planning stage, what matters is that the stack decision comes after scope, and that whoever proposes it can say in one sentence why it fits your goal and your team.
What are the phases of a website build, and how long do they take?
A build moves through five phases. Treat the durations below as relative weight, not fixed guarantees - the honest variable is scope and content readiness, not the stack. A five-page brochure site and a fifty-template product site both go through these phases; they just spend very different amounts of time in each.
| Phase | What happens | Relative time |
|---|---|---|
| Discovery | Goals, primary action, content inventory, scope lock, sitemap, success measures | Short - the cheapest phase to spend time in |
| Design | Wireframes, then visual design of key templates, review rounds, sign-off | Moderate - driven by number of unique templates and review speed |
| Build | Front end and any back end, CMS setup, content loaded, integrations, QA | Longest - scales directly with scope |
| Launch | Final QA, accessibility and performance checks, redirects, DNS, go-live | Short, but do not compress it - this is where rushed projects break |
| Care | Maintenance, updates, monitoring, fixes, and planned v2 work | Ongoing, for the life of the site |
Two things blow up this schedule more than anything technical: late content (above) and slow review cycles. If approvals take two weeks each, no amount of engineering speed rescues the date. Agree review turnaround times in the plan, in writing.
For what each phase costs, see pricing for the real numbers rather than a guess here. Budget follows scope, so a figure attached to undefined scope is fiction.
Planning for after launch
Launch is a milestone, not the finish line. A website is software, and software needs care: security and dependency updates, content changes, broken-link and uptime monitoring, and the v2 features you sensibly deferred. Decide before launch who owns this and how it is resourced. A site with no maintenance plan degrades quietly - slower, more exposed, and increasingly out of date - until it needs a rebuild that a modest ongoing budget would have prevented. That is what ongoing website maintenance is for.
How do I stop scope creep?
Scope creep is not caused by clients being difficult. It is caused by scope never being written down clearly enough to change deliberately. Prevent it with three habits:
- A signed scope with an explicit "out of v1" list. You cannot creep past a boundary that was never drawn.
- A change log, not a change argument. New requests are welcome; they go on a list with an impact on time and cost, and someone decides in or out. The request is not refused, it is priced.
- A parking lot for v2. Good ideas mid-build are common. Capture them somewhere visible so people feel heard without the current build absorbing them.
The goal is not to freeze the project. It is to make every addition a conscious trade against the timeline and budget instead of a silent one discovered at the end.
How do I write a brief that gets a useful quote?
A vague brief gets you vague quotes that are impossible to compare and easy to blow through. A good brief does not require you to know the answers - it requires you to state clearly what you do know. Include:
- The goal and the one primary action, in a sentence or two.
- A page list, even a rough one. This single item changes an estimate more than anything else.
- Content status - who is writing it, and whether it exists yet. Be honest; it sets the real timeline.
- Scope boundaries - what is in v1, and what you already know is v2.
- Must-have integrations - payments, CRM, email, booking, analytics.
- A real budget range and target launch window. Withholding budget does not get you a better price; it gets you proposals aimed at the wrong scale.
- Who decides - name the approver and the review turnaround you can commit to.
A brief with those seven things gets you comparable, accurate quotes and a partner who can push back usefully. A brief without them gets you a number that will change.
Bottom line
Plan in order - goal, content, scope, stack, timeline - and most of the expensive surprises never happen. The order is the whole discipline: each step constrains the next, so the platform and the schedule end up as conclusions you can defend rather than guesses you keep patching. Draw the v1 line hard, get content moving early, and treat maintenance as part of the plan rather than an afterthought.
When you are ready to turn a plan into a built site, that is what web design and development covers, the technologies page explains how the stack gets chosen for your job, and pricing has the real numbers once your scope is defined.