by
I’ve spent most of my career as either a writer, journalist, or content editor for indie publications, from dinky nonprofits to massive Buzzfeed-style media sites putting out video, audio, and news daily.
I’ve used...
WordPress and Wix for more than a decade
Great to get a basic site live, fast – with low upfront costs and no need for devs. But eventually – particularly when things start to scale – I've found myself increasing my floor time, box breathing, and praying to any goddess that listens.
Squarespace-style web builders
Fine if you’ve got an About page and a couple of blogs – but the moment you’re publishing media-heavy, constantly updated content, you start running into walls. And breaking down those walls takes time away from actually doing your job.
Even so, I never questioned any of it.
Yes, I’d whinge to myself as I wrangled workarounds – trying to get an image to sit on a page without rearranging the entire site, installing yet another plugin that created a new problem on top of my existing problem – but it all just felt like part of the job.
If I was lucky I’d nick a few minutes from the organisation’s one and only dev (always, always with a to-do list longer than an MP’s expenses claim), or find the solution in an ultra-specific Reddit thread from six years ago.
But it took working with Cursive – a digital agency that makes, amplifies, and supports web platforms for mission-led organisations – to understand what I’d been missing.
I’m a content manager… get me out of here!
When I first spoke to Cursive’s director, Rob, about what exactly he did, I had absolutely no idea what Wagtail was. He explained it as something like WordPress, but easier for editors and built for bigger, more complex websites.
That was enough to follow. But I didn’t really understand what a good CMS felt like until I started writing and editing in Wagtail properly.
Most editorial teams didn’t choose their CMS. Whether they’re part of a big organisation or an independent publisher, they likely inherited it. Or, they picked something that worked when they were one publication with two people, and haven’t had the time or funding to revisit it since.
The platforms that make it easy to launch – looking at you, WordPress – are perfectly designed for that moment. They’re excellent for getting something live quickly and cheaply to test whether the model works. That’s genuinely valuable.
But they weren’t designed for what happens next. When:
- You’re running multiple websites
- Your editorial team grows and different people need different levels of access
- You need one improvement to roll out across every publication at once, rather than rebuilding the same thing six times over
- The approval process moves out the platform and into a project management tool because the CMS has nowhere to put it
- You need your web platform to handle all kinds of unexpected requirements but it’s one more plugin away from a complete breakdown.
At that point, you hit a ceiling - and the web platform you launched on starts working against you.
What editors need from a publishing platform
Independent news publishers and think tanks aren’t running “blogs”. They’re managing reporters, editors, researchers, and freelancers across multiple departments, regions, and countries.
They’re handling long-form journalism and reports that go through multiple drafts, fact-checking, design, legals – all before signing off and pushing live.
They’re publishing time-sensitive news alongside evergreen reports alongside member-only content alongside reader donation flows alongside newsletters – often from the same interface, often under deadline.
Most platforms weren’t built for that. They were built for one person with one publication and full control over everything.
So the right publishing platform needs to:
Let different people do different things without getting in each other’s way. A reporter should be able to file without publishing. A city editor should be able to approve without accessing another title’s content. A senior editor should see everything. Platforms need clear permissions.
Keep content consistent across titles without duplicating effort. Shared content blocks – basically Lego for your editorial team – mean every title benefits from design and structural decisions made once, not rebuilt from scratch every time. Editors get creative control without having to moonlight as developers.
Hold the editorial workflow inside the platform. If your approval process has migrated into a project management tool or a chain of emails nobody can find a week later, your CMS isn’t doing its job. Drafts should have states. Reviews should be trackable. Sign-off should happen where the content is.
Support the varied content types you publish. Video. Pull quotes. Donation forms. Data visualisations. Long reads with rich media. Podcast embeds. Member-only content behind a paywall. Most publishing platforms support some of these, sometimes a bit awkwardly. The right one is crafted to handle all of them properly.
The platform literally built for publishers
WordPress was made for bloggers who needed more control. Squarespace was made for creatives who needed less. Wix was made for small business owners who needed something live by Friday. All of them do exactly what they were designed to do. None of them were built for an editorial team filing under deadlines all week long.
But in 2003, two developers at a newspaper in Kansas did actually build a web framework to solve this specific problem: How do you publish content fast, manage it cleanly, and give non-techy people enough control that editors can do their jobs without a dev on hand every time something needs to change?
That framework was Django. They open-sourced it in 2005, and it went on to become one of the most widely used web frameworks in the world.
Wagtail, the CMS that Cursive builds on, is built on top of Django. Made by UK agency Torchbox, it launched in 2014 out of frustration that existing options weren’t serving content-heavy organisations well. The mission was simple: editors should be able to get their best work done. It’s now used by NASA, the NHS, Mozilla, and Oxfam, among others.
The NHS chose it specifically because of editor experience – it had a large team of content editors with complex authoring and sign-off processes, and they needed a platform where the workflow lived inside the CMS, not outside it.
That’s Django’s newsroom origins at work: a platform informed by lived experience of large-scale publishing, deadline pressures, high turnover, and the need for a system that couldn’t be accidentally broken by whoever joined last month.
When scaling up starts to feel like a second and third job
What happens when you have multiple publications under one umbrella? Most publishing platforms weren’t designed to run more than one title. WordPress has a multisite feature, but ask anyone who’s managed one and you’ll get the look. Other platforms treat each title as its own separate world: separate content library, separate member data, separate infrastructure, everything. A design improvement, a workflow change, a new content block: if you want it everywhere, you do it everywhere, independently.
At one publication, you don’t feel any of this. At three, you start to. At five or six, you’re doing the same work five or six times, and the costs – in time, in money, in complexity – are also scaling. The right infrastructure works the other way: build something once and it’s immediately available across every title, every time. You can roll out an update from a single codebase, and manage users, permissions, and content all from one single source.
If you’re publishing things that matter, security isn’t optional
Finally, it goes without saying that independent publishers covering politics, press freedom, human rights, or anything that attracts powerful opposition are going to need a highly secure website. Django is known for its robust security, and Wagtail inherits that. Unlike WordPress, there’s no plugin ecosystem introducing vulnerabilities every time someone clicks install. If you’re a publisher with enemies – and independent journalism often means exactly that – it’s worth knowing your platform was built with that in mind.
Every serious publisher is going to face this decision eventually
The tools that work brilliantly at launch start to show their limits as your organisation grows – more impact, more titles, more team members, more content types, more readers who are paying and therefore expecting reliability.
Wagtail does require a development partner. You can’t self-serve your way into it the way you can with WordPress or Wix. For some publishers at earlier stages, the right answer is to stay on what’s working. But for publishers that have outgrown self-serve – where the platform is slowing everything down – the investment in proper infrastructure pays back quickly and keeps paying.
Most publishers get to the right platform eventually, but editors and content managers who get there earlier definitely spend less time lying on the floor box breathing.
