What kind of website do you actually need

Nearly every project starts with the same sentence. "We need a website." It is the least informative thing a client can say, and it is not their fault, because the word covers five different products that happen to share a browser.

Sorting yourself into the right category before anyone quotes you is worth more than any other decision you will make. Quoting the wrong category is how projects double in price halfway through.

The question that sorts it

Ask what has to change after launch, and who changes it.

Everything below follows from that. A site whose content is settled at build time is a fundamentally different piece of software from one you edit weekly, and both are different again from one your customers put data into. The visual design might be identical across all three. The engineering is not.

A brochure site

A handful of pages that say who you are, what you do, and how to reach you. The content is written once and changes a few times a year.

This is the cheapest thing to build and the easiest to underestimate the value of, because for a lot of businesses it is genuinely all that is required. If your customers find you, read three pages, and then call or message you, everything beyond those three pages is decoration you are paying to maintain.

The trap is asking for an admin panel "just in case". That is a second application behind the first one, and if you are honest about editing the page twice a year, it will cost more than it saves. Send the change to whoever built it.

A site you edit yourself

Same pages, but you add to them regularly. A blog, a news section, a menu that changes, a portfolio you keep adding to, prices that move.

Now the admin panel earns its cost, because the alternative is paying someone every week. This is where a content management system stops being overhead and starts being the point, and where an off-the-shelf platform is often the right answer rather than the compromise.

Be honest with yourself about frequency. Everyone believes they will publish weekly. Most people publish twice and stop, and then they have paid for and are maintaining an editing system nobody opens.

A catalogue or a shop

Products, prices, stock, payment, delivery. The moment money changes hands, you inherit tax rules, refund flows, payment compliance and a customer expecting an order confirmation.

A hosted platform beats a custom build here more often than a studio that sells custom builds likes to admit. If your catalogue is ordinary and your checkout is ordinary, you would be paying to rebuild something you can rent. Custom earns its cost when the thing that makes your business distinctive is the thing the template flattens, or when the buying logic is unusual: made to order with a lead time per item, a product configured before it can be priced, a deposit and a return window.

Either way the category is what matters. If you are in this one, you are buying an operational system rather than a set of pages, and it needs to be priced and planned that way.

A booking or scheduling site

Appointments, classes, tables, rooms, consultations. It looks like a brochure site with a form on it. It is not.

A booking flow has to know real availability, has to stop two people taking the same slot at the same moment, has to confirm somewhere the customer will actually see, and has to put the result in front of whoever runs the diary. Each of those is a small problem. Together they are the reason a booking site costs meaningfully more than the brochure site it resembles.

A web application

Accounts, logins, permissions, records that belong to particular people. A dashboard, a portal, an internal tool that replaces a spreadsheet several people are fighting over.

This is software that happens to be delivered through a browser. It is the most expensive category by a distance, and the one where the requirements are least likely to be fully known at the start, because nobody discovers what they need from an internal tool until they have used a version of it.

If you are here, the useful thing is not a full specification. It is agreeing what the first genuinely usable version does, and building that.

Why the category matters more than the features

A feature list is easy to price wrongly, because the same words mean different work in different categories. "Users can log in" is an afternoon on a brochure site with one admin and a fortnight on an application with roles and permissions. "Customers can get in touch" is a contact form in one category and a full booking system in another.

When you brief anyone, lead with the category and the after-launch question. "A brochure site, five pages, we will change it twice a year" gets you an accurate number quickly. "A website with some features" gets you a range so wide it is useless to both of us.

The most common misdiagnosis

Two categories up. It happens constantly, and it happens because building for a future you have not reached yet feels prudent.

The business that needs three pages and a phone number asks for a catalogue, because they might sell online one day. The business that needs a booking form asks for a portal, because customers might want accounts eventually. Both pay now for a maintenance burden that starts immediately and a use case that may never arrive.

Building the smaller thing does not close the door. A brochure site that works is a fine foundation for a shop in eighteen months, and by then you will know what the shop actually needs, which you do not know today.