What kind of website does your business actually need?
Most website projects start with a platform and work backwards. That is the wrong order, and it is why so many businesses end up paying to maintain capability they never use. This guide starts where the decision actually lives: what has to happen, for whom, and how often.
The short answer
Your website needs to be whatever shape lets the specific thing your business needs to happen, happen — and nothing more. For most businesses that is a lead-generation site: pages that explain the offer, forms that reach a human, and measurement that shows which pages produce enquiries. You only need a store, a booking engine, accounts, a portal or an application when a real business process cannot run without one. Every capability beyond that adds permanent cost in security, testing, hosting, upgrades, training and maintenance — so a feature should exist because it produces business value, not because it can be built.
Requirements before technology
There is a sequence to this decision, and every layer is derived from the one above it. Choosing WordPress, Shopify, Framer, Next.js or Supabase before you have worked down this list reverses the process: you commit to a set of constraints first, then discover what your business needed second.
01
Business goal
The commercial outcome, stated as a number if you have one. More qualified enquiries. Fewer phone calls about availability. Orders that do not need a person to process them.
↓
02
User action
The single thing a visitor must do for that outcome to occur. Submit an enquiry. Complete a checkout. Reserve a time. Log in and download a document.
↓
03
Feature requirements
What has to exist for that action to be possible. A form that validates and delivers. A cart that survives a page reload. An availability calendar that cannot double-book.
↓
04
Content requirements
What has to be on the page for someone to take the action, how much of it there is, and how often it changes. This is where the CMS question gets decided, not later.
↓
05
Integrations
Where the data has to go afterwards. A CRM, an accounting system, an inventory system, a scheduler, an email platform. Anything the business already runs and is not going to abandon.
↓
06
Admin requirements
Who edits what, who approves it, and what they must never be able to break. Also: who is on the hook when it goes wrong at 19:00 on a Friday.
↓
07
Security & data
What personal or financial data is collected, where it lives, who can reach it, and what obligation that creates. Accounts and payments both convert a website into a system holding other people's data.
↓
08
Scale
What breaks at ten times the traffic, ten times the catalogue, or ten times the users — and whether that is a realistic year or a fantasy quarter.
↓
09
Technology
Only now. The stack is a consequence of the eight answers above; if two platforms both satisfy them, the difference between the platforms is not the important decision on the table.
If someone quotes you a platform before asking you at least the first five, they are selling what they already build. That can still be the right answer — it is just not yet an argument.
Tick everything that is true about your business. Nothing is stored, nothing is sent, and the result updates as you go. The point is not the recommendation at the end — it is that each statement changes the build in a specific way, and you can see which ones you are actually signing up for.
The nine shapes
Almost every business website is one of these, or a deliberate combination of two. They are described by what they require rather than by what they are built with, because the requirements are what you are committing to.
Brochure websiteProve the business is real, competent and reachable.＋
When it is enough
Work arrives by referral, phone or walk-in, and the website's job is to confirm that you exist and are worth calling. This is a legitimate answer, not a starter tier — a fast, well-written five-page site beats a neglected twenty-page one every time.
What it actually requires
—Clear services, real proof of work, and human contact details
—Fast loading and a layout that works on a phone
—Correct business information wherever it appears online
The expensive mistake
Adding a blog nobody will write, a shop with no products, and a booking system for a business that books by text — then paying to maintain all three.
Lead generation websiteTurn traffic into enquiries you can attribute and measure.＋
When it is enough
The sale happens in a conversation, not in a checkout — services, trades, professional firms, consultancies, agencies, B2B. This is what most businesses actually need, and where most website budgets are best spent.
What it actually requires
—A page per service or offer, written to be found and to answer objections
—Forms that validate, reach a human, and are protected against spam
—Analytics and conversion tracking that attribute enquiries to pages
—Somewhere the enquiry lands and is followed up — an inbox is a system too
The expensive mistake
Measuring traffic instead of enquiries. A page that ranks and converts nobody is a cost centre with good posture.
SEO / content websiteEarn traffic continuously by owning the questions your buyers ask.＋
When it is enough
Your market searches before it buys, and you can commit to publishing for a year rather than a quarter. Without that commitment this shape is the most expensive way to own an empty archive.
What it actually requires
—A content architecture: one page per intent, deliberately internally linked
—A CMS someone will actually use, with structured content types
—Structured data, clean URLs, and a sitemap that stays accurate
—A publishing rhythm, and someone whose job it is
The expensive mistake
Publishing volume instead of coverage. Fifty thin posts compete with each other; ten pages that genuinely answer a question do not.
Ecommerce websiteSell products without a person handling the transaction.＋
When it is enough
You have products, stock and a fulfilment process. If you have three products and sell mostly in person, a page and a payment link may serve you better than a store.
What it actually requires
—Catalogue and variants, with product content that actually sells
—Stock that agrees with reality, wherever reality is kept
—Checkout, tax, shipping rules, refunds and order records
—Fulfilment, returns and customer service — the parts that are not software
The expensive mistake
Treating the store as the project and the product pages as filler. The catalogue is the website; everything else is navigation.
Where buying beats building
For most merchants, a hosted commerce platform is the correct answer: checkout, payment compliance and security become someone else's problem. Building a bespoke checkout is justified when a business rule genuinely cannot be expressed on a platform — not because the platform is unfashionable.
Booking websiteLet people reserve time or capacity without a phone call.＋
When it is enough
Availability is the thing customers actually want to know, and answering it manually is costing you hours or bookings.
What it actually requires
—Availability and capacity rules that cannot be violated
—Confirmations, reminders, cancellations and no-show handling
—Whatever your staff already use to see the day's schedule
The expensive mistake
Building a reservation engine. Double-booking, time zones, daylight saving and cancellation policy are solved problems with expensive edge cases.
Where buying beats building
Integrate proven scheduling or reservation software and design the site around it. Restaurants in particular should assume the reservation platform is infrastructure, not a feature — guests arrive through it, and rebuilding it buys you nothing a guest can see.
Membership websiteSell continued access to something, and revoke it when payment stops.＋
When it is enough
There is genuinely valuable material or community behind the gate and a recurring reason to return. Otherwise you have built a paywall around a library nobody visits twice.
What it actually requires
—Accounts, subscription billing, plan changes and cancellations
—Access control that is enforced on the server, not hidden in the interface
—A retention plan, because churn — not signup — decides whether this works
The expensive mistake
Gating content that was better used to attract customers. Some material earns more in public than behind a login.
Customer portalGive each customer their own information and workflow, privately.＋
When it is enough
Customers currently email you for status, documents or history, and answering costs real staff time. The portal is justified by the volume of those requests, not by how modern it looks.
What it actually requires
—Strict per-customer data isolation, designed and then tested
—Authentication, permissions, an audit trail and account recovery
—Integration with wherever the real data lives today
—A support path for the day someone cannot get in
The expensive mistake
Building the portal before the process. If the internal process is inconsistent, the portal makes the inconsistency visible to customers.
Internal business toolLet staff do the work faster and with fewer mistakes.＋
When it is enough
A process runs on spreadsheets and memory, breaks when the person who knows it is away, and costs more in errors than it would cost to build.
What it actually requires
—A process that is written down and agreed before anything is built
—Roles, permissions and a record of who changed what
—Speed of use over visual polish — this is a tool, not a brochure
—Training, and someone who owns it after launch
The expensive mistake
Rebuilding software you could buy. The case for building is fit — when the way you work is the advantage and off-the-shelf tools force you to work like everyone else.
Where buying beats building
If a standard product covers eighty per cent of the process, buy it and build only the part that is genuinely yours.
SaaS / web applicationDeliver software as the product itself.＋
When it is enough
People pay for what the software does, not for what your company does. At that point the website is marketing for a product, and the product is a separate build with its own roadmap.
What it actually requires
—Product scope, a release process, and environments beyond production
—Accounts, billing, support, uptime expectations and a security posture
—A marketing site that can move at a different speed from the application
The expensive mistake
Pricing it like a website. A questionnaire cannot scope a platform — the requirements are the expensive part, and they do not exist yet.
Combinations are normal and often correct. A clinic is a lead-generation site plus integrated booking. A brand with wholesale accounts is a store plus a portal. A software company is a marketing site plus an application. What matters is that you know it is two things: they get separate scopes, separate release cadences, and usually separate budgets — and the marketing site should never be blocked waiting for the application.
Do you actually need a CMS?
A content management system is a workflow decision wearing a software label. Answer these before naming any product — the answers rule most of the options out.
Who edits — one owner, a marketing person, or several people across departments?
What they edit — words and images, or structured records like services, staff and products?
How often — a few times a year, monthly, or several times a week?
Approvals — can the editor publish directly, or does something have to be reviewed first?
Languages — one, or several that must stay in step with each other?
Publishing — does anything need to be scheduled, embargoed or expired automatically?
Structure — is the content repeating records with fields, or genuinely one-off pages?
No CMS
Content lives in the codebase and changes ship with a deployment.
Content changes a handful of times a year and one person owns the site. Fastest and cheapest to run, with no admin surface to secure or upgrade.
Every wording change waits on a developer. That is fine at four changes a year and unbearable at forty.
Hosted CMS
An all-in-one platform where editing, hosting and templates come together.
A non-technical owner needs to change most things themselves and the design does not need to be unusual. Lowest friction to edit, and the platform handles updates.
You inherit the platform's limits and its pricing, and unusual requirements get expensive quickly.
Headless CMS
Content lives in a separate system with an API; the site renders from it.
Content is structured and reused — the same service record appearing on a listing, a detail page and a form — or several channels consume it, or several editors need roles and approvals.
Two systems to run, a modelling exercise up front, and a real difference between a good and a careless content model.
Ecommerce CMS
A commerce platform where products, inventory and orders are first-class and pages come along with them.
Selling is the primary job. Products, stock, tax and checkout are handled by software whose entire purpose is that, and merchandising stays in the merchant's hands.
The content and blogging side is usually weaker than a dedicated CMS, so a heavy content strategy needs planning around it.
Custom admin
An editing interface built specifically for this business's records.
The content is genuinely your domain — inventory with your rules, client records, scheduling constraints — and a general-purpose CMS would force staff to translate their work into someone else's model.
You now own an application, including its security, upgrades and training. Justified by daily use, not by preference.
The right answer is the lightest option that survives your actual editing pattern for two years. Most businesses over-buy here: they pay for a system built for a publishing team, then update the site twice a year through the developer anyway.
What you should be able to change yourself
Ownership is not all-or-nothing. Some things should always be a few clicks away from the business owner; others should stay behind a development and deployment process, because changing them casually is how sites break, lose rankings, or quietly stop collecting enquiries.
What
—
Why
Page copy and headlines
You change it
Your offer changes faster than any release schedule.
Blog posts and articles
You change it
Publishing cannot depend on someone else's availability.
Services and descriptions
You change it
What you sell is yours to describe, and it changes.
Staff, bios and photos
You change it
People join and leave; a stale team page reads as neglect.
Products, prices and stock
You change it
Commercial decisions cannot wait on a deployment.
Images and galleries
You change it
New work should be publishable the week it finishes.
Locations and opening hours
You change it
Wrong hours cost you customers and damage local search.
FAQs
You change it
They come from real customer questions, which arrive constantly.
URL structure and redirects
Changed through development
Casual URL changes are the fastest way to lose accumulated rankings.
Page templates and layout system
Changed through development
A drag-and-drop layout tends to degrade into an inconsistent one.
Structured data and metadata rules
Changed through development
It has to stay consistent site-wide to mean anything to a search engine.
Forms, delivery and integrations
Changed through development
A silently broken form is invisible; changes need testing, not confidence.
Analytics, consent and tracking
Changed through development
It carries privacy obligations and breaks measurement when edited carelessly.
Access, permissions and payments
Changed through development
Security changes need review. This is the one place where friction is the feature.
The cost of complexity
Every capability has a lifecycle, and the build is the cheapest part of it. This is the arithmetic that decides whether a feature is worth having — not whether it can be built, which it almost always can.
Development
The one cost everybody counts, and usually the smallest over five years.
Testing
Every feature multiplies what has to be re-checked before anything ships.
Security
Logins, uploads and payments each add a surface someone has to keep watching.
Hosting
Databases, background jobs and file storage cost more than static pages, monthly, forever.
Monitoring
Anything that can fail silently needs something watching it, or you find out from a customer.
Upgrades
Dependencies age. Software that is never updated becomes software that cannot be updated.
Training
Every admin interface has to be learned — again, each time staff change.
Maintenance
Content drifts, integrations change their APIs, and browsers move on. Nothing stays finished.
A feature should exist because it produces business value, not because it can be built. If nobody can name the process it improves or the money it makes, it is not a feature — it is a liability with a nice interface.
Six businesses, reasoned through
The same sequence, applied to real situations. Note that none of these start from a platform, and two of them conclude that the ambitious version would be a waste of money.
Local contractor or trade
The goal
More qualified enquiries from the surrounding region, and fewer calls asking questions the site could answer.
What follows from it
—A page per service, written the way customers describe the problem
—Proof: real project photos, real reviews, service area stated plainly
—A form and a click-to-call that both work on a phone in a truck
—Local search presence and consistent business listings
The shape
A lead-generation site with light content editing. No database, no accounts, no store. The budget belongs in the service pages and the proof, because that is what decides whether the phone rings.
What we would not build
No customer login, no quoting engine, no booking system. Quotes for this kind of work need a site visit, and a form that captures the job details does the same work with none of the upkeep.
Be the obvious credible choice when someone researches a problem they have never had before.
What follows from it
—Authority content answering the questions clients actually ask first
—Practice-area pages that map to how people search, not to the org chart
—Named people with real credentials — trust in these fields is personal
—A contact path that respects confidentiality and sets expectations
The shape
An SEO and content website with lead generation attached, and a CMS with approval workflow — because in regulated professions someone senior has to sign off before anything is published.
What we would not build
No client portal in the first phase. It is a legitimate second project once the document exchange volume justifies it, but it should never delay the site that brings the clients in.
Fill tables, and stop answering the phone to questions about hours and menus.
What follows from it
—Menu, hours, address and parking — findable in under five seconds, on a phone
—Reservations, taken reliably at the moment someone decides to come
—Photography that makes the room look like the room
—Correct information on the map listing, which most people see first
The shape
A marketing site with proven reservation infrastructure integrated into it. Guests arrive through the reservation platform your floor staff already trust; the website's job is to send them there without friction.
What we would not build
Do not rebuild reservations. Double-booking, waitlists, deposits and no-show policies are solved problems whose edge cases are expensive, and a guest cannot tell who wrote the booking widget.
Sell directly, at margin, without a person touching each order.
What follows from it
—Catalogue with variants, sizes and stock that agrees with the warehouse
—Checkout, taxes, shipping rules, returns and refunds
—Product content that does the selling — photography, fit, materials, care
—Email flows for abandoned carts and repeat purchase
The shape
Ecommerce on a hosted commerce platform. Checkout, payment compliance and platform security stop being your problem, and the budget moves to product pages and brand — which is where the conversion difference actually lives.
What we would not build
No custom checkout, and no bespoke inventory system before there is inventory. Revisit only when a specific business rule genuinely cannot be expressed on the platform.
Attract qualified enquiries and stop losing hours to itinerary admin and status questions.
What follows from it
—Destination and specialism content that earns search traffic
—An enquiry flow that qualifies before it books time in a calendar
—A CRM holding the client relationship, not a mailbox
—Somewhere clients can see their own itinerary and documents, eventually
The shape
A hybrid, built in that order: content and lead generation first, then a client area once the volume of status emails proves the case. The public site earns the clients; the portal reduces the cost of serving them.
What we would not build
Not both at once. A portal built before there are enough clients to fill it is maintenance without return, and it delays the part that produces revenue.
Win work publicly while replacing the spreadsheets the business actually runs on.
What follows from it
—A credible public site that sells the capability
—An internal tool that matches the real process, written down first
—Roles, permissions and an audit trail
—Integration with the accounting or scheduling system already in use
The shape
Two products: a public website and custom internal software. They share a brand and almost nothing else — different users, different success measures, different release cadence.
What we would not build
Do not put staff tools behind a login on the marketing site to save money. It complicates the public site, constrains the tool, and gives both a worse security posture than either would have alone.
Write an answer to each of these before you talk to anyone about building it. It takes an afternoon, it makes quotes comparable, and it is the difference between buying a website and commissioning one.
Goal and action
The commercial outcome, in one sentence, with a number if you have one
The single action a visitor must take for that outcome to happen
How you will know it worked, and who looks at that
Features and content
The pages that must exist at launch, and who writes them
The repeating content types — services, staff, products, locations, FAQs
How often each changes, and who changes it
Which languages, and who keeps the second one current
Systems and admin
Every system this must exchange data with, and whether it has an API
Where an enquiry or order goes after it is submitted
Who edits, who approves, who has an account, and what each may never break
Data, scale and upkeep
What personal or payment data is collected, and where it lives
What realistic growth looks like in twelve months
Who maintains it, on what budget, and who is called when it breaks
What you are deliberately not building in phase one
The last line is the one that saves the most money. A written list of what is out of scope is worth more than a longer list of what is in it.
Questions
What kind of website does my business actually need?
Most businesses need a lead-generation website: pages that explain the offer, forms that reliably reach a human, and analytics that show which pages produce enquiries. You need a store when you sell products directly, a booking site when customers reserve time, accounts when something genuinely private sits behind a login, a portal when customers need their own records, and an application when the software itself is the product. Anything beyond what your business process actually requires adds permanent cost without adding revenue.
How do I choose between a brochure site and a lead generation site?
Ask where the work comes from. If it arrives by referral and the site's job is to confirm you are real, a brochure site is sufficient and a bigger one is waste. If you need strangers to become enquiries, you need conversion built in from the start: a page per service, forms that reach a human, and conversion tracking. The difference is measurement — a lead-generation site can tell you which pages produced enquiries, and a brochure site cannot.
Do I need a CMS for my website?
Only if someone non-technical needs to change content without a developer, or content changes more than a few times a year. If one person owns the site and it changes rarely, no CMS is the fastest and cheapest option. If content is structured and repeating — services, staff, products, locations — a structured or headless CMS earns its keep. If approvals or several languages are involved, that rules out the simplest options and is a genuine reason to accept a heavier one.
Should I choose the platform before writing requirements?
No. Choosing WordPress, Shopify, Framer, Next.js or Supabase before the requirements exist reverses the decision: you commit to a set of constraints first, then discover what the business needed second. Work down business goal, user action, features, content, integrations, admin, security, scale — and only then technology. If two platforms both satisfy those answers, the choice between them is not the important decision.
When should I build something instead of buying it?
Build when the way you work is the advantage and off-the-shelf software would force you to work like everyone else. Buy when the problem is already solved and its edge cases are expensive — payments, scheduling, email delivery and commerce checkout are the usual examples. If a standard product covers about eighty per cent of the process, buy it and build only the part that is genuinely yours.
What happens to my website if traffic grows ten times?
For a content or brochure site, much less than people expect: static pages served through a CDN absorb that without changes. The pressure appears when there are logins, carts or live database queries, where the database gives way before the pages do. The practical answer is to keep the public site static wherever possible and let the dynamic parts scale separately, which is an architecture decision, not a hosting upgrade.
Where to go next
You have requirements. These are the next decisions, roughly in the order they matter.