Discipline
Web platforms that hold up.
Sites and publishing systems built to carry real editorial load — many pages, several languages, more than one team touching them — without slowing down as they grow.
The argument
A website is a product with editors inside it.
Most sites are built once and then defended. A second language arrives, a campaign needs a landing page by Thursday, someone wants a section that does not exist yet — and every change becomes a ticket for a developer. That is not a content problem. It is a structural one.
We build the other kind. Pages are composed from a small set of tested sections with typed properties, so a new page is assembled from parts that already work in every language and both themes. The layout stays consistent because there is nothing loose left to misuse.
Underneath it is ordinary engineering: typed content, rendered on the server, cached at the edge, measured on the devices your readers actually hold. Speed here is not a launch-day number. It is what the site still does after two years of publishing.
What we deliver
What a platform engagement includes.
Every line below is something you can open, run or hand to somebody else.
Information architecture
A page and URL structure agreed before design starts, with redirects mapped from whatever exists today.
Section library
A tested set of page sections with typed properties, so a new page is composed rather than coded.
Editing model
Who can change what, where it is reviewed, and how a draft becomes a published page without a deploy.
Localisation
Every string in every language from the first commit, rather than an English site with translations bolted on later.
Performance budget
Agreed limits on page weight and interaction cost, checked in the pipeline so a regression fails the build.
SEO surface
Metadata, canonicals, hreflang, structured data, sitemap and redirects generated from the content instead of maintained by hand.
Accessibility
Contrast, keyboard paths and screen-reader semantics tested in both themes, as part of the build rather than an audit afterwards.
Handover
Runbooks, an editor's guide and a walkthrough with the team that will publish on it after us.
How a platform gets built
Five steps from audit to publishing.
The order matters more than the tooling: structure first, sections second, content last.
Audit
We read what you already publish — the pages, the languages, the analytics and the things editors quietly work around. Nothing is rebuilt before we know what it was doing.
Structure
Content types, page templates and the URL map, written down and reviewed with the people who publish, before a single screen is designed.
Sections
The component library is built and tested first, in both languages and both themes. Pages come afterwards and cost almost nothing.
Migration
Existing content moves across with its history and its links intact, and every old address either keeps working or points somewhere sensible.
Launch
A rehearsed cutover: performance and accessibility checks green, monitoring on, and your editors publishing on the new platform rather than waiting on us.
Walkthrough
Composing a page from tested sections.
A page assembled from library sections, with no developer in the loop.
Under the hood
You inherit the workshop, not only the site.
A platform is only as good as the things around it. You get the pipeline that builds and checks every change, the preview environment editors use before publishing, and the tests that fail loudly when a section stops behaving.
All of it runs in your accounts, under your keys. If you take the work in-house next year, there is nothing to hand back.
- A preview address for every branch, shared with editors.
- Performance and accessibility budgets enforced in the pipeline.
- An editor's guide written for people who do not read code.
Stack
What we build platforms with.
- Next.js
- React
- TypeScript
- Tailwind CSS
- next-intl
- Node.js
- PostgreSQL
- Sanity
- Storybook
- Playwright
- Vercel
- Cloudflare
- AWS
- Redis
Chosen per project — the stack your team already runs usually wins.
The two projects above are illustrative examples rather than real engagements — no client is named and no figures are claimed.See the work index
Questions
Common questions about platform work.
The four that come up on most first calls about a rebuild.
Which CMS do you use?
Whichever fits the way your team actually publishes. We work with headless systems, with content kept in Git, and with a small custom editor where the content model is unusual.
The choice comes after the content model, never before it.
Can you migrate our existing site?
Yes, and the redirect map is part of the deliverable. Old addresses either keep working or point somewhere sensible, so search results and inbound links survive the move.
We run the migration twice: once as a rehearsal on a copy, once for real.
How many languages can it hold?
As many as you publish in. Language is part of the content model from the start, so adding one later is a content job rather than a rebuild.
Right-to-left layouts need design work as well as engineering, and we will say so before you plan the timeline.
What happens after launch?
Your team publishes and we step back. Where you want us to stay close, we do it as a defined weekly commitment for platform and dependency work, agreed in advance.
Either way, the site is never hostage to us being available.
Next step
What slows your editors down?
Send the address of the site you have now and the thing it stops you doing. We will reply with what we would change first, and whether a rebuild is even the right answer.