News and publishing platforms
Writing, editing, scheduling and publishing — with the reader side built to stay up when a story lands, and the editorial side built so more than one person can work on the same edition without overwriting each other.
Talk about scopeWhat we would build
Static where it can be, dynamic where it must
An article is the same for every reader, so it should be rendered once and served from a cache close to them. Comments, personalisation and live blogs are not, and they belong on a separate path that can be slow or fail without taking the story with it. Drawing that line early is what makes a spike survivable.
Publishing is a state machine with people in it
Draft, edited, approved, scheduled, live, corrected, withdrawn. Each transition has a person and a time attached, and some of them are not reversible by whoever made them. This is the same shape as an approval workflow in any system of record, which is the part of it we have built many times.
Two people on the same piece at deadline
Concurrent editing is normal in a newsroom, not an edge case, and last-write-wins loses somebody's paragraph on the day it matters most. Either the system merges properly or it locks explicitly and shows who holds it — silently discarding an edit is the one option that is not acceptable.
Media is most of the payload
Images and video dominate the weight of a news page, so they decide whether it opens on a phone on a slow connection. Derivatives generated on upload, correct formats served per device, and a hard rule that an editor cannot accidentally publish an eight-megabyte original.
A correction has to be visible as one
Editing a live article silently is a credibility problem rather than a technical one. The change is recorded, the earlier version is retained, and where the change is material the reader is told — and all of that has to reach the caches and syndication the original already went out through.
Archive that stays addressable
Old stories keep earning traffic for years, so URLs are permanent, restructuring the site does not break them, and a piece from six years ago still renders in the current template. Publishing platforms that treat the archive as cold storage discover its value the first time they migrate.
The traffic is not steady, and that is the whole problem
A news site is quiet and then, without warning, it is not — one story is picked up and the audience arrives in minutes rather than months. Nothing else we build has that shape. It means the reader-facing side has to be cheap to serve and cacheable to the edge, and it means the expensive, personalised or interactive parts have to be separable so they can fail without taking the article down. A platform where every page view reaches the database is fine until the day it matters.
The article, its images, the section fronts. Identical for every reader, so the spike costs bandwidth and nothing else.
Comments, personalisation, the live blog. Kept on a separate path so it can degrade or fail without taking the story down with it.
Publishing is a workflow with real gates
Draft, subbed, legalled where it needs to be, scheduled, live — and the ability to pull something back. Several people touch the same piece near a deadline, so concurrent editing and a visible history are requirements rather than refinements. The system has to answer who changed this line, and when, without anyone reconstructing it from memory.
Published is not final
Stories are corrected, updated and occasionally retracted after they are live and after they have been shared, cached and indexed. A correction has to be visible as a correction rather than a silent edit, the original has to remain in the history, and the change has to propagate through every cache the article reached. This is the part that separates a publishing platform from a blog, and it is rarely in the brief.
What we would want settled before an estimate
Whether the reader side and the editorial side are one deployment or two — it changes the hosting, the failure modes and the cost of a traffic spike more than any feature does.
Whether anything is behind a paywall or a registration wall. Metering, entitlement and the interaction with search-engine crawlers is a substantial subsystem, and it is either in scope from the start or it is a rebuild.
How many people edit at once at peak, and whether they are in the same building. That decides whether concurrent editing needs real merging or an honest lock.
What we would not build
A theme marketplace, or a layout the newsroom can rearrange freely. Total layout freedom sounds generous and produces pages nobody can make fast or accessible, and it is invariably used once during setup and never again.
An in-house comment system, on a first build. It is a moderation product, not a feature, and it carries an obligation that outlasts the enthusiasm for having it.
A recommendation engine before there is enough traffic to train one. Categories and a good archive answer the same need until the numbers justify more.
When not to build this
A packaged product is the right answer more often than a development company usually admits, and if your problem is an ordinary one that something off the shelf already solves, we will tell you so rather than quote for it. What follows is the case for the other answer — the conditions under which building is worth what it costs.
The workaround has become the process
A packaged system that mostly fits leaves a residue — the spreadsheet kept alongside it, the step done by hand every month, the field used to mean something it was not named for. When that residue is where the actual work happens, you are already maintaining custom software, just without any of the benefits of having built it.
The thing you do differently is the thing it cannot do
Every business has a few processes that are genuinely its own, and those are usually the ones it competes on. Off-the-shelf software is built for the average of a sector, so it handles the ordinary parts well and the distinctive part not at all. Building is worth it exactly where that overlap fails, and rarely anywhere else.
A vulnerability shared by every deployment
A vulnerability in a packaged product is a vulnerability in every deployment of it, and attackers only have to find it once. A system built for one business is not on that list.