Content platform
Giving a bilingual site's content back to its editors
Every string on a bilingual market operator's site lived in code, so a comma was a developer ticket. I moved the copy into a headless CMS without letting the market data follow it.
- Interface copy moved from code to the people who write it
- 309 stringsInterface copy moved from code to the people who write it
- One document per page carrying both languages, right-to-left verified
- Two localesOne document per page carrying both languages, right-to-left verified
- Market data deliberately kept out of the CMS
- Feed ≠ contentMarket data deliberately kept out of the CMS
The client
A financial market operator in the Gulf region with a bilingual public site. Communications and market data sit in the same interface but have completely different owners, review cycles and failure consequences.
The engagement
A build pairing the existing site with a headless content platform, delivered with a seeded, editor-ready content model.
The problem
A bilingual front end had all of its copy — headings, labels, disclosures, both languages — hard-coded. Every wording change was a developer ticket, and the two language versions drifted apart because nothing forced them to be edited together. The tempting fix is to move everything into a content system, including the parts that are not content.
What I did
I drew the line first: interface copy, pages and news belong to editors, but market data is a feed and stays out of the CMS regardless of how convenient it would be to treat it as text. The interface strings moved into the content system behind a fallback overlay, so the site still renders its built-in copy if the CMS is unreachable — a content platform should not be able to take the front page down. The localisation model was fixed so both languages live on one document rather than two, which is the failure mode that quietly breaks publishing and the editing interface at the same time. Then I spent real time on the editing experience, because a content platform nobody enjoys using becomes a developer ticket again within a month.
What was built
A monorepo pairing site and CMS: structural pages as single types, news as a collection, both languages carried on one document, several hundred interface strings served from the CMS over a built-in fallback set, and a branded editing experience with labelled and grouped fields and working preview.
On the table at the end
- Monorepo with site and content platform
- Localised content model with a fallback overlay
- Branded editing experience with preview and seeded bilingual content
What it changed
Removed the development team from routine copy changes and stopped the two language versions drifting apart, while keeping the market data feed out of a content system where a well-meaning edit could have consequences.
How it ran
- 01
Separate content from feed
Editorial copy, pages and news into the CMS; market data, tickers and charts explicitly excluded and documented as such.
- 02
Model the pages properly
Single types for structural pages, a collection for news, shared components for repeated blocks, all localised at field level.
- 03
Overlay, not replacement
Interface strings load from the CMS over a built-in default set, so an outage degrades to the shipped copy instead of a blank page.
- 04
One document, two languages
Both locales on the same document, asserted at seed time — the alternative silently produces two records and breaks publishing and editing together.
- 05
Editor experience as scope
Branded administration, field labels, grouped edit views, working preview, and realistic bilingual content seeded to hand over on.
Other work
All case studies →- Industrial operations
A command centre demo that ends in a work order
Operations people do not buy dashboards, they buy what happens after the dashboard. I built the demo so every insight terminates in the maintenance system, in the client's own brand.
- Financial services
A proposal the client could click
Predictive models were running and nobody could see them. I shipped the assessment as a working prototype on synthetic data rather than a document, then survived the meeting that changed the cloud, the tool and the pilot customer.
- Consumer IoT
Shipping a wearable app before the wearable existed
A child-safety product whose hardware was not ready. We built the MVP against a mocked device contract instead of waiting, and shipped without the usual collapse when real constraints arrived.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.