Borrowing the Chrome: When the CMS Stopped Making Sense

The Editor Every Newsroom Built Twice

Walk through any major newspaper from the late nineteen-eighties through the two thousands and you would find something curious. Every single one of them had built a text editor. Not adopted, not configured — built. The Atex systems at the wire services, the early Hermes installations at the Guardian, the CueSheet rigs at the Washington Post, the various flavors of NewsGate and Methode and the rest. Every newsroom had its own opinionated piece of software that journalists typed into, and every one of those pieces of software was someone's full-time job to maintain.

The reasoning at the time was reasonable. Journalists, the argument went, are not like other office workers. They write to length. They write to a wire service style guide. They need to send a story into a queue, get edits back, push a final version to the layout system, all without losing the headline that was decided in the morning news meeting. A normal word processor cannot do this. So we will build our own.

What none of those projects could have known is that they were building roughly the same software, badly, in parallel, hundreds of times. Most of those editors are dead now. The newsrooms still exist. The workflows still exist. But the custom-built editor running on a Sun workstation in nineteen-ninety-six is in a landfill somewhere, and the journalist who used it for fifteen years now writes in Google Docs alongside everyone else.

What the Bespoke Built Was a Meeting

Here is the part that took the industry decades to name. The reason every newsroom built its own editor was not really technical. It was political. The custom system was the only place where a hundred different opinions about how journalism should work could be encoded and frozen into something tangible.

When a section editor wanted the headline character count to update live in the corner of the screen, that became a feature. When a copy desk wanted style guide warnings to fire on certain word choices, that became a feature. When the publisher wanted print and web versions to share a story body but diverge on the deck, that became a feature. Every one of these decisions was a fight. Every one of these decisions ended in code. And once it ended in code, nobody could re-fight it without convening another meeting, with the same people, on a Tuesday.

The custom system was, in software form, a record of who won which argument. The user interface was just the visible top of an organizational iceberg. And the reason the software was so expensive to maintain was that the iceberg was still there, underneath, generating new arguments every quarter. A new section launches, a new ad format gets sold, a new editor takes over the lifestyle desk. Each of these triggers another round of small fights, each of which has to be encoded somewhere, and the encoding lives in the software.

This is the same reason a hundred thousand small businesses ended up running a popular blogging platform with custom themes that nobody dared to upgrade. The plugins, the modified comment system, the dozen tiny modifications — those were not just code. They were artifacts of decisions, frozen in PHP, where reopening them meant reopening the meeting that produced them.

The Collapse Nobody Quite Noticed

Something quiet has happened in the last two years and not many people have called it out by name. The cost of writing custom software has collapsed. Not by some incremental percentage. By something closer to an order of magnitude, for the right kinds of projects.

A solo operator, working with a good AI coding tool, can now produce a bespoke editorial interface in a week that would have taken a media company three months and four engineers in twenty-twenty. The numbers are loose, but the direction is clear. And the implication is genuinely strange. If bespoke is suddenly cheap, then a lot of the reasons companies use generic software stop holding up at their foundations.

[calm]

The deep reason the big blogging platforms exist is that fifteen years ago, the cost of building your own publishing system was higher than the cost of accepting the platform's opinions about everything. That math has reversed for an interesting category of users. If you are one person with one workflow, building your own thing tailored exactly to you is now the cheaper option. The platform was always going to be a compromise. Compromise is what you pay for when bespoke is too expensive. When bespoke gets cheap, the compromise stops looking like a deal.

But Bespoke Is Still a Trap

Here is where it gets interesting, and where the chrome metaphor comes in.

The seductive version of this realization is to build everything from scratch. New publishing system. New editor. New comment threads. New autosave logic. New keyboard shortcuts. New undo stack. New revision system. New mobile editing experience. And to write all of it personally, because AI can help, and because you have opinions, and because this is your tool and nobody else is going to use it anyway.

This is, for the most part, a mistake. Not a moral mistake. A practical one. The reason is that the chrome of editorial software, the actual interface elements, has been solved many times by people who thought hard about it for years. Inline editing, comment-on-selection, document diffs, draft states, autosave indicators, mobile composition — these are not novel problems. There are open source projects, mostly with permissive licenses, that have solved them in ways that work and have been beaten on in production for a decade.

What is novel about your tool, if you are running a small newspaper or a small consultancy or anything else with strong opinions about its own workflow, is the editorial logic on top. The way an article moves from interview to print. The way the AI error-review fits into the pipeline. The way ads slot in next to copy. The way the print version diverges from the web version on the night before deadline. That part is yours, because nobody else has your exact workflow.

The clean version of the new wave of bespoke software is this combination. Borrowed chrome underneath. Bespoke editorial logic on top. The combination is what a media organization of any size could not have built three years ago — not because it was technically impossible, but because the meetings to agree on it would have killed it before the first commit landed.

What You Borrow and What You Build

A useful way to think about the line. The borrowed layer is anything that would be roughly the same shape regardless of what you are building. Rich text editing. Keyboard shortcuts. Undo and redo. Comment threads. Diff views. File uploads. Image handling. User session management. These are not your competitive advantage. Nobody is going to use your tool because your autosave indicator pulses in exactly the right way.

The built layer is anything that encodes a decision specific to your situation. For a one-person newspaper, that might be the article pipeline from interview to print. For a consultancy, it might be the proposal workflow. For an indie game studio, it might be the asset review process. These decisions are what the tool is actually for. Everything else is plumbing.

The trick, and this is where browsing other people's code matters, is recognizing which is which before you start typing. A lot of solo builders end up building plumbing because the AI is enthusiastic about helping them build plumbing. The cost of plumbing has collapsed too, which makes it tempting. But the cost of plumbing collapsing is not a reason to build it. It is a reason to borrow it cheaply and spend your saved time on the part that is actually yours.

A Quiet Permission

There is something almost permission-granting about realizing all of this. For two decades, the answer to "what should I use to publish my newspaper" was a kind of triage between bad options. You could pay for an expensive proprietary system that came with a contract and a sales team. You could install the popular blogging platform and accept its compromises. You could spend a year building your own and then spend the rest of your career maintaining it, which nobody could afford to do alone.

The fourth option was not really available, because it required a kind of software production that did not exist. Build your own, tailored to exactly you, borrowing every solved piece from the commons, encoding only the decisions that are actually yours. That option exists now. The fact that media companies have not yet figured out how to do this is not because it is technically impossible. It is because the meetings would kill it before anyone shipped anything.

[serious]

The advantage of being one person is that the meetings cannot kill it. There is only you. And the chrome is right there in the attic, in a thousand small repositories, waiting to be borrowed.