The split is not about page count
Projects are often sorted by size: five pages is a brochure, fifty is a platform. That is a poor test. A three-page site that records registrations is a platform, and a forty-page purely editorial site is still a brochure.
The right test is memory. A brochure shows content you decided in advance and serves it to everyone the same way. A platform records what visitors do and gives it back: an account, a booking, a basket, a case file, a history.
The moment a visitor produces data that someone will have to look at later, you need a database, an admin interface, a backup policy and a position on personal data. That is a different project, and a different budget.
The signals that you have outgrown a brochure
A form that arrives by email is still a brochure. The day someone asks how many enquiries came in this month, or who has not been called back yet, email stops being enough: you need a database and a screen to read it.
Other signals: several people must see different things depending on their role, content must publish on a date, stock or availability must be accurate right now, or a client must find their own history by logging in.
Each of those, taken alone, looks like a small feature. Put together, they describe an application. That is why a project started as a brochure drifts: the requests arrive one at a time and nobody notices they add up to something else.
The trap of the brochure that becomes a platform
The expensive scenario is always the same. The site is built as a brochure, with no database and no accounts, then one feature is added, then another. Each addition is grafted onto a foundation that was not designed for it, and within months the cost of the next feature exceeds what a proper foundation would have cost at the start.
The reverse also happens and costs just as much: building a platform for a brochure need. You pay for an architecture of accounts and roles nobody uses, and you take three months to launch what should have taken three weeks.
The only way to avoid both is to decide explicitly, during scoping, what the site will have to remember. That question fits in one sentence and prevents both mistakes.
Moving from brochure to platform
If you are clearly a brochure today but the need is coming, the right strategy is not to build everything now. It is to ship the brochure on a foundation that can take the rest: a real development environment, a code repository, hosting that accepts a database, and content modelled without assuming it will stay frozen.
That precaution costs very little. Its absence is measured in a full rebuild.
The comparison
| Criterion | Brochure site | Business platform |
|---|---|---|
| What the site remembers | Nothing, content is decided upfront | What visitors produce |
| Database | Often unnecessary | Essential |
| Admin interface | Content editing | Business screens and roles |
| User accounts | None | Authentication and permissions |
| Personal data | A contact form | Processing to declare and secure |
| Typical timeline | Three to six weeks | Two to six months |
| Main cost centre | Design and content | Business logic and back office |
In short
You are a brochure if the site presents, explains and connects, and if every enquiry can leave by email without anyone needing to count them.
You are a platform the moment data produced by a visitor has to be read back, filtered or edited by someone else. Budget and calendar then change scale, and it is better to know at scoping than at the third change order.
When in doubt, list what someone will need to look up in six months. If the list is empty, it is a brochure.