“If a journalist had started Uber, they would have decided they wanted to build their own cars,” American media innovator Jim Brady told us. “Why use the fleet that’s out there when we can make our own stuff? Because then we can control everything.”
Jim has spent three decades in American digital news, running newsrooms, funding them, advising them on technology. He says control is the reporter’s craft. You ask the questions, you work your list, you decide when the interview is over. “You might not get what you want, but you kind of control the situation.” That instinct builds careers in journalism. A startup then asks its founder to trade it away: “When you go to a startup, you realize how much of that you have to give up if you actually want to run a business.”
An additional challenge is that technology was invisible in a benign way for decades. “Somebody handed you a laptop,” Brady says. “The website went down, it was back up ten minutes later. You didn’t know how, you didn’t know who. It was just sort of like water coming out of a faucet. You just assumed it would be there.” A founder who leaves that world inherits the entire waterworks overnight (publishing, payments, deliverability, user accounts) on top of the journalism. Reaching for control, the one professional instinct that has always delivered, is an entirely understandable first move.
Build what makes you unique, buy everything else
We first asked our cohort to rate two statements from one to five. “Technology infrastructure had a direct effect on our ability to grow revenue” produced near-consensus: seventeen of twenty-one rated it a four or five. “Underinvestment in technology created bottlenecks that limited growth or efficiency” split the sample almost exactly in half: ten felt the cost, nine avoided it.
We also asked every outlet how it sourced ten technology functions, both at launch and today: through open-source software, in-house development or products bought on the market. The clearest movement is toward vendors. Count every change of arrangement between launch and today (functions added, systems replaced) and a majority ends with a supplier product: more moves went toward vendors than toward all other destinations combined. Connected to this is a retreat from self-hosted open-source arrangements, which roughly halved as the outlets matured.
There are also a few regretted builds. One outlet launched with a self-built identity system that its founder now calls “the biggest mistake, I would never do it again.” It subsequently moved the system to suppliers and redirected its developers toward community tools, the area in which the organization really does something no one else does. Another publisher’s homemade paywall produced “bugs and bugs and bugs,” in the founder’s weary summary, and they are now looking for an integrated replacement from a large vendor.
Even a successful internal build does not necessarily make a successful technology product. Several outlets created tools that worked well for their own newsrooms, then ran into much larger problems when they tried to productize and sell them: a system built around one organization must become configurable for many; someone must handle sales, onboarding and customer support; and the product needs its own roadmap, investment and management. The few software ventures in our cohort that crossed that divide were largely spun out of the newsroom into separate companies and run as what they had become: technology businesses. We return to them briefly in “The next fifteen years” chapter.
Two ways to get boxed in
Media technologists described two versions of the same trap. In the first, a technical co-founder assembles a system (often standard software under layers of custom additions) and keeps it working for years while technical debt accumulates. Eventually the codebase ages or its original architect leaves, taking with them much of the knowledge of how it works. In the second, an agency builds the system, leaving every repair, integration and new feature dependent on the original contractor.
Running your own technology also means running a product: someone must manage developers, set priorities, translate between editorial, audience and revenue needs, and decide what gets built next. Larger organizations employ chief product officers and teams to do this. A small newsroom may hire developers without having anyone equipped to direct their work, increasing the cost while still producing frustrating results.
It’s hard to compare the costs of building versus buying. A vendor’s platform fee appears as one visible expense; the costs of the cheaper system are scattered across hosting, contractors, plugins and staff time. One adviser described walking publishers through costs that reached $25,000, more than the platform fee they had rejected as unaffordable. Newsrooms often reach a stable arrangement only with their second or third system, after discovering how thoroughly broken technology can take time from journalism.
The city and the off-grid cabin
Kim Bode heads growth initiatives at Newspack, the sponsor of this chapter. Her analogy for shared infrastructure is municipal: living in a city means the trash is collected, the water runs and the trains come without your involvement, and in exchange you accept that the trash is picked up at a certain time every week. “You can choose to live off the grid,” she says. “But in most cases it just doesn’t make sense.”
Her argument has four layers. The first is financial: maintenance will cost money regardless of whether it sits with a single vendor or across a patchwork of solutions. Still, shared infrastructure tends to be more cost effective. The second is speed. A publisher building alone can move only as fast as its own team; on a shared platform, it inherits features already developed for organizations with similar needs. “You share what the need is, so you can share the solution,” Bode says, “and then you can make it your own,” through the settings, the design and the way it fits into the newsroom’s workflow.
The third layer is the accumulated experience of the community. Publishers can see what peers have tried, what worked and, just as usefully, what did not. Support compounds in the same way; whatever the question, someone has usually asked it before. Finally, there are the boundary-pushers: the few publishers experimenting ahead of everyone else, lately, Bode notes, with AI. When one of them discovers something useful, the lesson travels across the platform. “It really helps to lift them all up.”
She is also clear about the limits. A publisher that would use a fraction of the platform should probably buy something simpler. Also, a publisher whose requirements sit far outside the shared roadmap strains both sides.
She argues that sharing the plumbing does not dissolve the newsroom’s own technical ambitions; it redirects them. Developers freed from checkout flows and data plumbing, get to build “some really interesting tool that is bespoke to your community,” the unique layer, on top of the common one.