“What is a service in your business?” — the question that decides your site

The most valuable conversation in a web project has nothing to do with how the site looks. It happens before any design exists, and it goes like this: what things does your business actually have, and what does each one consist of?

It sounds like a formality. It is the single decision that most determines whether the site still works in three years.

What content modelling is

Websites are usually described in pages. Businesses do not have pages, they have things: services, vehicles, courses, properties, locations, projects, people. A page is one way of looking at a thing. It is not the thing.

Content modelling is writing down what those things are, what fields each has, and how they relate. It is unglamorous and it takes an afternoon, and skipping it is why so many sites become unmaintainable.

Here is the version of this conversation that changed a project.

A vehicle rental company in Warsaw. The obvious model: vehicles, with a photo, a type and a price. Straightforward — an afternoon’s work.

Then the actual question: who rents from you?

A courier firm taking a van for a day. A company putting a van on a twelve-month contract instead of buying one. A crew needing a nine-seater for a season. And a driver whose own car is in the workshop after somebody else’s accident, whose rental is being paid by an insurer under a liability policy.

Four customers. Four completely different sets of paperwork, pricing logic, duration rules and decisions. The insurance case is not even really a rental in the commercial sense — it is a claim process that happens to involve a vehicle.

The naive model has one vehicle type and one enquiry form. It works, and it quietly loses three of the four customers, because three of them do not recognise themselves anywhere on the site.

The real model has the vehicle as a record and the contract type as its own concept, with its own rules and its own path through the site. One catalogue, four ways in. The finished system runs a hundred and fifty-one vehicle records across four custom types.

That is not a design decision. It came out of a conversation about how the business works, and no amount of visual polish would have compensated for getting it wrong.

Why the wrong model is expensive later, not now

A bad content model is cheap on launch day and expensive forever afterwards. The costs arrive in this order.

Editing becomes manual repetition. If a “service” is just a page, then a service appearing on the home page, in the navigation, in a comparison table and on its own page means four places to update. Somebody will update three.

Nothing can be listed, filtered or sorted. If your projects are pages, you cannot filter them by type, because a page has no type. Adding filtering later means restructuring content that already exists — which is a data migration, not a feature.

Relationships have to be maintained by hand. “Which instructor teaches this course” is either a real link between two records, or a name typed into a text field. The typed name is fine until the instructor’s name changes, or until you want a page listing everything they teach.

Extension means rebuilding. A properly modelled site adds a new category by adding a record. A badly modelled one adds it by copying a template file and editing it.

Every one of those is invisible during the project and obvious in year two, which is precisely why the conversation gets skipped.

The questions I ask

For each type of thing the business has:

• What is one of these? Get the noun exact. “Course” and “course session” are different things if the same course runs three times a year.
• What does it always have? Required fields. If it can be missing, it is not required — and the interface must handle its absence.
• What does it sometimes have? Optional fields, and what the page looks like without them.
• What is it connected to? Instructors, locations, categories, related items. Each connection is a real relationship, not a piece of text.
• How do people find it? This determines what must be a filterable field rather than free text. If customers search by transmission type, transmission cannot be a sentence in a description.
• Who edits it, and how often? Fields that change weekly need to be easy to reach. Fields set once at creation can be tucked away.
• What happens when it is retired? Deleted, archived, hidden but kept for records? Sold vehicles and discontinued courses do not simply vanish from a business.

Two hours of this reliably changes the shape of a project more than any other two hours in it.

How much structure is too much

The opposite failure is real. I have seen sites with twenty custom types where five would do, each with thirty fields, most of them empty, and an editing experience so heavy that the client went back to sending changes by email.

The test I use: a thing deserves its own type if it has its own fields, its own listing, or its own address.

A charity I worked with ended up with ten custom types, and each one earns its place — rescue stories, community centres, programmes, partners, tenders, reports. They have genuinely different fields and genuinely different pages. A rental company has four. A church directory has three. A simple corporate site often needs none at all beyond what WordPress ships with, and adding them is over-engineering dressed as professionalism.

More types is not better modelling. Fewer types than the business actually has is worse.

Model first, design second

There is an order to this that matters.

If you design first, you produce a beautiful page for one course, and then discover that eleven of the hundred and thirteen courses have two instructors and the layout has room for one. Now you either change the design late or misrepresent the business.

If you model first, the design is a treatment of a known structure. You already know a course can have several instructors, that some have no fixed schedule, that a few are online-only. The layout is built to hold what actually exists.

This is why my first deliverable on a project is usually not a picture. It is a document listing every type of thing the business has, every field it carries, and every relationship between them. Clients are sometimes surprised by that, and then about half of them tell me it clarified something about their own business — which is not a claim I make for a mockup.

The short version

Ask what things your business has before you ask what pages your site needs. Write down the fields. Write down the relationships. Decide who edits what, and what happens when something is retired.

It is an afternoon at the start of the project. Skipping it does not save the afternoon — it moves it to year two, where it costs a migration instead.