00 / Case study
Less architecture.
More magazine.
M&A Review has covered mergers and acquisitions since 1990. When the group came to me, it had just paid a significant sum for a website built on far more technology than a magazine needs, and it showed: slow pages, missing features, and a paywall that kept nobody out. I rebuilt it as one Statamic site that does the simple things well, and we have been building on it together ever since.
-
03
Brands on
one codebase -
430
Issues,
back to 1990 -
2,169
Old URLs
still resolving -
00
Password resets
for readers
- Client
- M&A Media Services GmbH
- Role
- Sole developer
- Stack
- Statamic
- Since
- 2025, ongoing
01 / Starting point
The site had been built by a well-known agency and had passed through several hands by the time it reached me. Underneath was a Statamic backend that rendered nothing itself, and two Next.js applications, one per magazine, doing work a template could have done. Features had been cut along the way, and what remained was slow and fragile. This is what I found when I opened the code:
Two front-end apps where the second was a copy of the first, built and deployed separately, so every fix had to be made twice
A paywall that ran in the browser. Every article, paid or not, was sent in full with the page and only hidden once it had arrived
E-papers uploaded folder by folder over FTP, with no paywall at all, just a hard-to-guess address
A page builder where nearly every block carried its own background, overlay, height, padding and margin settings, which made editing slow and the control panel slower
Article lists built in the browser after the page loaded, so they were missing from the HTML search engines read
2,686 redirects from the old site written into code, so changing one meant a deployment
None of it needed a headless architecture. A magazine is pages, lists and a login, and Statamic is the perfect tool for exactly that.
02 / Constraints
- The archive keeps its addresses
- M&A Review has been published since 1990, and its articles are linked from far outside the site. Every old URL had to arrive somewhere sensible, which made the redirect map a deliverable rather than an afterthought.
- Subscribers keep their logins
- Readers moved across with the passwords they already had. No reset campaign, no gap in access, and no support queue of people locked out of something they had paid for.
- Institutions stay subscribed
- Universities and firms subscribe by IP range or email domain rather than by individual login. That access had to carry over group by group, for IPv4 and IPv6 alike.
03 / What I built
-
B/01
One codebase, three magazines
All the brands share templates, components and content. A brand is a color theme and its own settings, so adding the UK edition in June 2026 took just a few settings in the control panel rather than a new application.
-
B/02
A paywall on the server
Access is decided before the page is rendered, and a reader without it never receives the article. Subscriptions run through Stripe, and universities and firms get in by IP range or email domain. Pages stay cached, and the paid part is loaded only once access has been checked, so it never enters the cache.
-
B/03
E-papers
An issue's e-paper is several hundred files in a dozen folders. The editors now upload it as a single zip in the control panel, where it is unpacked automatically and kept where nobody can open it directly. Here too, access needs a subscription.
-
B/04
The archive
The M&A Review archive back to January 1990, with every article linked to its issue and its authors. The 2,169 redirects from the old site live in the control panel, where the editors can change one without asking a developer.
-
B/05
Fast by default
Pages are rendered on the server and served from a cache, so a reader gets finished HTML instead of a page that assembles itself in the browser. Only the parts that depend on who is logged in are loaded separately.
-
B/06
A new page builder
Editors pick a section and fill in the content; the layout is already decided. Issues, covers and articles come from where they already live, so on the new pages, one publish updates everything that shows them.
04 / What changed
-
What there is to maintain
- Before
- A headless Statamic backend and two near-identical Next.js apps.
- After
- One Statamic site.
-
A paid article
- Before
- Sent to every visitor in full, then hidden in the browser.
- After
- Rendered on the server, for readers with access only.
-
Publishing an e-paper
- Before
- A folder uploaded over FTP, hidden behind a random name.
- After
- One zip in the control panel, behind the same paywall as the articles.
-
Publishing a new issue
- Before
- Several pages edited by hand to swap in the new content.
- After
- Published once. Pages on the new builder update themselves.
-
Launching a magazine
- Before
- Copy the entire app, then build and deploy it separately.
- After
- A new site with its theme and settings. M&A Review UK launched this way.
-
Changing a redirect
- Before
- Edit a 13,500-line code file and redeploy.
- After
- Edited in the control panel.
05 / Ongoing work
The page builder is being replaced section by section. As each page moves across, what it left behind goes with it: unused images and files, and code for workarounds that are no longer needed.
A simpler access model is built and ready to go live. Instead of choosing subscriber groups for each article, editors set one default per magazine (free, registered or subscriber), separately for articles and e-papers, and mark individual articles or issues as free where needed.
With the site running as intended, the focus is shifting to new features. The client has a long list of them planned.
06 / Next step
Inherited something similar?
A build that stalled, or a codebase nobody wants to touch. Show me what state it is in and you get an honest answer on whether it is worth rescuing.