Example

Work / Logistics

One platform for every market.

A logistics operator ran a separate website in every country it served. Each campaign was rebuilt from scratch, market by market.

Role
Web platform, design system
Year
2024
Scope
Architecture, build, migration
Stack
Next.js · TypeScript · PostgreSQL

An illustrative example. No client is named here until we have their written consent.

Client
Logistics firm
Sector
Logistics
Team shape
One platform engineer, one designer, alongside the client's editors
Handover
Documented, walked through, then a support window

Case notes

What the work involved

The problem as we found it, what we changed, and what that made possible.

The operator had grown by acquisition, and every market it entered arrived with a website of its own. By the time we were called in, the marketing team was maintaining a set of sites that shared a logo and almost nothing else.

Challenge

Publishing anything meant publishing it repeatedly. A price change, a service page, a hiring notice — each was retyped into a different admin, in a different language, by a different person, and the versions drifted within days. Nobody could say with confidence what a given market was actually showing.

Approach

We began by reading the sites rather than the brief: what each market genuinely needed to say for itself, and what only looked local because it had been rebuilt locally. Most of it was the same page with a different phone number.

From that we built one platform with a shared component library and a content layer per market. A market can override a page, a section or a single line, and everything it does not override follows the centre. Editors work in their own language, on the same structure everywhere, so a new market launches from parts that already exist.

Outcome

A campaign is now written once and released across markets on the same day, with local exceptions handled as exceptions rather than as copies. The engineering that used to be repeated per site happens once, and publishing no longer waits on an engineer.

The platform

One structure, many voices.

The problem

One page, maintained many times over.

Each market had its own stack, its own editor and its own idea of what a service page should contain. The differences were rarely deliberate — they were the residue of whoever built that site first.

The cost showed up as delay. By the time a campaign reached the last market, the first market had already changed it.

  • One page structure, rewritten per country.
  • Translations that no longer matched their source.
  • Every release waiting on an engineer.
Before: one site per market.

The approach

A centre that holds, with room to move.

The platform keeps one component library, one content model and one deployment. A market inherits everything by default and overrides only what it can justify — a section, a page, a single sentence.

Editors never open a template. They see the same fields in their own language, and what they publish carries the same structure the centre publishes.

  • Shared components, versioned in one place.
  • Per-market overrides, visible as overrides.
  • A new market starts from parts that exist.
After: one platform, local overrides.

In their words

We publish once and every market gets it the same day. The work that used to be coordination is now just editing.
Tijana MarkovićExampleCommunications leadLogistics firm

An illustrative quote from a placeholder case study — not a real client statement.

Detail

The parts an editor actually touches.

This case study is an illustrative example. The client, the quote and every image on this page are placeholders, and no real engagement is described.Back to all work

Next step

The same site in several markets?

Tell us where your content has to land and what genuinely has to differ between those places. We will say plainly whether one platform is the right answer, and what the first two weeks would look like.