Not 14 Websites. A Machine That Produces Websites.

Recently, we completed one of the most ambitious digital engineering projects our team has undertaken.
On paper, it looked like this: 14 enterprise websites, multiple business units, regional sites, shared corporate content, strict governance, enterprise security, accessibility requirements, on-premise infrastructure — and a delivery timeline of just three and a half months.
Most teams would immediately spin up 14 CMS installations. Fourteen admin panels. Fourteen search engines. Fourteen maintenance headaches. We didn’t.

It all started with reframing the problem. Instead of asking “How do we build 14 websites?”, we asked “How do we build this so the fifteenth website is easy?”
That one shift changed everything.

Instead of asking how do we build 14 websites, we asked how do we build this so the fifteenth is easy.

One of my engineers jokingly asked, “Do we really need fourteen CMSs?”
That simple question led us down a completely different path. Instead of fourteen independent systems, we designed an architecture powered by just four Strapi CMS instances. This is where our deep experience with custom CMS development came in.
Think about it — four backend systems now power fourteen independent digital experiences. Each business unit manages its own content. Each regional team has its own publishing workflow. Yet the engineering team does not maintain fourteen separate platforms.
Less infrastructure. Less maintenance. Less duplication. More control. That is the kind of engineering that defines a seasoned website design company — and it is what we do as a full-stack development company, building both the front-end user interface and the back-end server architecture while staying ready for whatever challenge comes next.

Imagine your company announces a sustainability initiative. Marketing wants it on their site. Corporate wants it. Regional websites need it. Media relations wants it. Investor Relations references it.
Now ask yourself — should someone paste the same article into five different CMSs?
Of course not. We created what we call a Domain-Key Content System, where every article carries a simple set of domain tags. Publish it once. The platform automatically knows which websites should display it.
No duplication. No synchronisation headaches. No forgotten updates. No editorial nightmares.

Sometimes the smartest engineering is not about writing more code. It is about making sure nobody has to repeat work.

Search is one of those features everyone assumes is easy — until you have fourteen websites.
We built a single Algolia-powered enterprise search platform that intelligently serves all fourteen sites. Visitors only see results relevant to the website they are browsing. Editors do not need to think about indexing. Developers do not maintain fourteen search infrastructures.
One search platform. Fourteen digital experiences. Simplicity for users, elegance under the hood.

People often ask how the websites scored so well on performance. The honest answer? We did not optimize for speed. 
Using Next.js, Incremental Static Regeneration, intelligent caching, and Akamai CDN, we designed the platform so that pages are generated efficiently, refreshed only when content changes, and delivered quickly to users worldwide.
The result: 90+ Web Vitals scores across the platform. Not because someone spent weeks squeezing out Lighthouse points at the end of the project — but because performance was a design decision from day one.

We did not optimise for speed. We architected for it. Performance was a design decision, not an afterthought.

Many projects follow this sequence: build, test, launch, run a security scan, fix everything, repeat. We flipped that around. Security was not something we “added” — it influenced every architectural decision we made.
Role-based access. Private infrastructure. Dependency reviews. Secure deployment pipelines. Vulnerability management. Continuous validation.
Fixing a security issue in production is always more expensive than preventing it during design.

Let us get one thing out of the way. Yes, we used AI. No, AI did not build fourteen enterprise websites.
People often imagine AI replacing developers, but that is not what happened here. AI handled repetitive tasks — generating boilerplate, refactoring code, improving documentation, speeding up testing. Meanwhile, our engineers focused on the things AI still cannot do well: designing architecture, making trade-offs, balancing governance with flexibility, and solving business problems.
The result was an enterprise platform delivered in three and a half months without compromising quality. That is what happens when experienced engineers use AI as a force multiplier rather than a shortcut.

People often congratulate us for delivering fourteen websites. That is nice, but it is not what I am most proud of.
What made the difference were the decisions that will keep paying dividends long after the launch announcement is forgotten. Four CMS platforms managing fourteen websites. A single search platform serving an entire digital ecosystem. Regional teams working independently without losing governance. Shared content published once and appearing wherever it should. Performance, accessibility, and security designed into the platform — not bolted on later.

As CTOs, we sometimes obsess over technology — frameworks, languages, cloud providers, CMS platforms. But clients rarely remember those. They remember whether their digital platform became easier or harder to manage.
What clients need is a platform where marketing can launch faster, regional teams feel empowered, security teams sleep better, and the next project becomes simpler instead of more complicated.
That is the real job of technology. Not to build impressive architectures, but to quietly remove complexity.

The best enterprise architectures are the ones your users never notice but your teams appreciate every single day.

The internet does not need another website. It needs better-engineered digital platforms — fast without being fragile, secure without becoming difficult to manage, flexible without becoming chaotic, and scalable without multiplying costs.
That is the kind of engineering we believe in. If this project taught us anything, it is this: the best work is the work that makes the next project easier.