Platforms for audiences and revenue

Custom and headless publishing platforms, membership and paywall systems, newsletter infrastructure and audience dashboards, built for speed, scale and editorial ease. The requirement most often underweighted is the editor experience: a platform that is technically excellent but awkward to publish into will be resented by the people using it every day, and they will find workarounds that undermine the structure. We design the editorial workflow alongside the reader experience, because your newsroom’s throughput is as much a business constraint as your page speed.

Yes. We build content assistants, recommendation and personalisation engines and semantic search on current model stacks including Claude. In publishing the recommendation work usually returns most, because increasing pages per session directly affects advertising yield and subscription conversion. On AI assisted writing we would encourage a clear editorial policy first: Google’s guidance targets content produced primarily to game rankings rather than AI use as such, but scaled unreviewed output is exactly what that policy is aimed at, and it puts a publisher’s credibility at risk for limited gain.

Yes. We integrate content management, advertising, email and payment systems and build the paywall and membership logic, so audience and revenue data stay connected rather than living in separate tools. The design decisions that matter commercially are the metering rules, what a reader can access before hitting the wall, and how the wall behaves for visitors arriving from search or social. Those choices trade reach against revenue directly, so we build them to be adjustable and measurable rather than fixed in code.

Yes, and it is a defining requirement in publishing because your traffic is inherently unpredictable. A single story can multiply normal load within minutes, and that is precisely when the audience is most valuable and least forgiving. We build with aggressive edge caching so most readers are served without touching the origin, static generation where content permits, and infrastructure that scales horizontally. We also rehearse the failure modes, because degrading to a cached version is far better than becoming unreachable during the one story that would have grown your audience.

You do, completely. You receive clean, documented, well structured code and full ownership of everything we build, held in your own repositories from the first commit rather than transferred at the end. For publishers this matters because the platform and the archive are core business assets with long lifespans. You should never be in a position where a supplier relationship constrains what you can do with your own archive, and you should be able to change provider without a migration that risks your back catalogue.

A high performance site typically goes live in eight to fourteen weeks. A custom content management or membership platform runs fourteen to twenty six weeks depending on scope and integrations, and we agree a clear timeline up front. Content migration is regularly underestimated: moving an archive of many years with inconsistent formatting, embedded media and legacy URLs is usually the largest single task, and it determines the date more often than feature development does. We assess archive quality during discovery rather than after committing.

Cost depends on scope, traffic scale and which advertising and subscription systems we integrate. We scope to your goals and budget and send a fixed proposal, usually within 24 hours. The variables that move the number most are archive migration volume and the number of revenue systems involved, rather than page templates. We will say when a requirement is disproportionately expensive relative to the revenue it can realistically produce, since for most publishers the priority order is speed, then subscriptions, then everything else.

Usually yes, though it requires discipline about which advertising partners you keep. We rebuild against the Core Web Vitals thresholds, Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1, while keeping your advertising stack functional. Most layout shift in publishing comes from ad slots that are not given reserved space, which is fixable. The harder conversation is that some third party tags cost more in lost readers than they return in yield, and we will show you which.

Carefully, because the two pull in opposite directions and the answer depends on your business model. Google requires that whatever it can index is what a reader arriving from search actually sees, so the supported approach is structured data indicating paywalled content rather than serving search engines a full article that readers cannot read. Cloaking risks the traffic you depend on. In practice most publishers land on metering or partial access from search, and we build that so you can adjust the rules and measure the trade off rather than guessing once.

Yes, and migration is often the main body of work rather than a preliminary step. We map every existing URL to its destination so the archive keeps its search equity, preserve metadata and structured data, migrate media rather than leaving it on the old host, and reconcile the result against the source rather than assuming a clean import. Archives are usually messier than expected, with inconsistent formatting accumulated over years and content types nobody remembers creating, so we audit the archive before quoting rather than after.

It is a genuine commercial decision rather than a technical one, and worth making deliberately instead of by default. AI crawlers can be allowed or disallowed individually in robots.txt, which is the mechanism the major operators publish and honour, so you can permit some and refuse others. The trade off is real: blocking protects content from being used in training and answers without compensation, while allowing it can produce citation and referral traffic. Some publishers have negotiated licensing instead. We implement whichever position you take and make it easy to revise.

Yes. Every build includes thirty days of post launch support, and beyond that we continue with development support, monitoring, security patching and new features, and can provide content services and editorial workflow help so both the platform and the pipeline keep performing. For publishers we would rather report on subscriber conversion, returning readers and revenue per session than on raw traffic, because a sessions figure inflated by a single viral story tells you very little about whether the business underneath is actually growing. We also keep watching Core Web Vitals after launch, since advertising tags are added over time and performance tends to erode quietly unless somebody is measuring it.