One source of truth: how the site builds itself from the catalog

Until a month ago we kept our services in two places. In the database, with their prices, features and case studies, which is what the agents use to sell. And on the website, hand-written in a copy file.

Every change meant touching both. It never fails: one gets updated and the other goes stale. The site claimed five services while the database had seven, and the sales pitch on the site was not the one the agent was telling clients over chat.

The underlying problem was not duplication

It was that nobody knew which of the two was correct. When a fact appears in two places and they disagree, you do not have information: you have an argument.

The obvious way out was to pick a winner. And that is where a more interesting design decision showed up: where does the commercial grouping live?

Because the database had operational categories: campaigns, social media management, AI assistants, automations. Those are what the system needs in order to bill and execute. But a client does not buy "social media management," they buy "marketing." The grouping the client sees and the one the system uses are not the same thing.

The missing layer

We added a layer above categories: service families. Marketing groups campaigns and social. AI Agents groups assistants and automations. Websites is a single category. Custom Software is another.

The key part is that the grouping went into the database, not the site. Each category declares which family it belongs to and whether it gets published. Hosting exists in the catalog but is not published, because it comes included and selling it separately would compete with our own model.

We also fixed something we had been dragging along: custom development lived inside the websites category, so "custom" showed up in two places in the menu and neither was clear. Now it has a family of its own.

How the site assembles itself

The site requests a catalog from the API and builds everything from it: the services menu, each family page, and each product page with its features and published case studies. That is thirty-eight generated pages, in two languages, without a single hand-written list in the frontend.

Loading a new product in the admin publishes it on the site. No deploy, no code change, nobody having to remember to update the other side.

One detail worth flagging: prices do not travel. The catalog endpoint returns names, descriptions, features and cases, but no amounts. That is a commercial decision, not a technical one: prices get discussed with an agent, not listed in a table. Having the endpoint simply not return them makes the decision impossible to break by accident.

What it cost

One schema migration, one data migration, a new endpoint, and updating the seed. Half a day of work to replace something that already worked.

The way to justify that kind of work, when somebody asks why touch what is not broken, is to count how many times a month you had to edit in two places and how many times one of them went stale. Once you do that arithmetic honestly, the half day pays for itself in the first month.