Sixteen publications run on one codebase. When we fix a thing, it is fixed on all of them. When we launch a new one, we do not write a website. We add a row.
This is the front end: the part of the stack a reader actually touches. Here is how it works and what it has let us do.
One site that knows which publication it is
Every request to any of our domains hits the same application. The first thing it does is read the domain and look it up. cltmercury.com is The Charlotte Mercury. farmingtonmercury.com is The Farmington Mercury. easthamptonmercury.com is the East Hampton Mercury, which did not exist yesterday. The publication record tells the site its name, its logo, its colours, its beats (the coverage areas), its time zone, its email address and its analytics identity, and the site renders itself accordingly.
The design is one system with expressions. The Charlotte Mercury and The Farmington Mercury share a newspaper grammar: lead story, secondary grid, beat navigation, author pages. Strolling Firethorne has its own warm palette. The racing paper runs dark. Mercury Local, the site you are reading, has its own chrome entirely. Underneath, the same components, the same routes, the same rules about how a URL is built and what a page carries for search engines.
Every article page carries a machine-readable summary that search engines and, increasingly, AI agents read: the publisher, the author, the date, the image with its dimensions, the breadcrumb, the organization. Every publication has its own sitemap, its own news sitemap covering the last 48 hours, and its own feed. Every legacy address from the WordPress years redirects to where the story lives now. None of that is done per publication. It is done once.
What "add a row" looks like in practice
Strolling Firethorne, March 31: a full publication from zero in a day. Domain, homepage, colours, twenty articles, twenty-four tags, eleven pages. The sixth publication on the platform, and the first one built after the migration rather than moved by it.
Fourth Ward Charlotte, April 24: the eighth live domain, with eight hub pages, a forty-eight-stop walking tour, a buildings directory of seventeen pages and eight articles across three bylines. Seventy-six reader-facing addresses on launch day.
The East Hampton Mercury, September 24: concept to launch, twenty-four sources filed and twenty-eight items live, the sixteenth publication.
I am not claiming those were effortless days. They were long days. I am claiming that none of them involved building a website, because the website already existed. The work was the journalism and the setup: the beats, the sources, the pages a town needs on day one.
Where it runs
The application is built on Next.js and deployed on Vercel, which puts every page on a global network close to the reader and rebuilds the site automatically when we push a change. When a story is edited, the database tells the site, and the page is fresh within the second. That last part took real work to get right, and we wrote about that in the piece about the half-second we found in the layout.
Why this is the model
The hard argument for local news has never been whether a town wants coverage. It is whether the cost of standing up a publication can be brought down far enough that a small town gets one at all. On WordPress the cost of the fourth site was the same as the first. On this platform the sixteenth took less to launch than the sixth, because every fix since has come with it.
That is the whole bet, stated as plainly as I can: one codebase that gets better for every publication when it gets better for one. Charlotte is where it was proven. It was never the ceiling.
This is No. 14 in We Built Our Own. Previous: One database is the whole company. Next: What AI actually did.