Future of News

A framework for newsroom build vs buy decisions.

13 Oct 2025 — 8 min read

Someone in the newsroom needs a new tool. The audience team wants better dashboards; the graphics team needs to publish interactives faster. An engineer says, “we could build that.”

They probably could. But a few months later, the prototype still isn’t done, priorities have shifted, and maintenance has quietly become a huge problem. Multiply that story by a few years and you have the technology landscape of many newsrooms: a constellation of one-off tools, each built with the best intentions, each demanding time that no one has.

That’s where the build vs buy dilemma begins.

Introducing build vs buy

You have a problem that needs to be solved using software of some kind. The question is, do you build it yourself, or do you buy it from a vendor?

Every technical team encounters this at some point. It’s a decision that seems simple on the surface but regularly destroys engineering roadmaps and budgets.

Your engineers might want to build it. It’s why they got into this profession, after all. What’s the point of being an engineer if you’re not, you know, engineering?

As a writer who is also an engineer, I’m in love with building things from scratch. Being able to create something out of words on the page is a kind of magic, regardless of whether it’s prose or code. Many of us got into the profession because that act of creation gave us energy; I certainly did. We love to build, to create, to invent.

But sometimes that’s the worst thing we could be doing.

Newsrooms are not tech companies

In a tech company, software is the thing that makes us special. We’re probably all working on different aspects of the same product, or at least the same product suite. We then make money by honing the software product for its audience and either selling it to them or monetizing the traffic.

In an organization like a newsroom, our product is not software. We depend on software at every level from gathering source material to publishing to an audience, but software is not the thing that most people would say is valuable about us. Ask anyone what’s valuable about us and they’ll tell you that it’s the journalism that we produce that you can’t get anywhere else. That’s our differentiating value. People subscribe or donate to the journalism, not the software we build.

This radically changes how we think about investing in software.

Newsroom tech teams are like startups in that they’re running with limited resources and constantly trying to assess how they can provide the most value. Back when I was Director of Investments at Matter Ventures, I advised them to spend their time building the things that made them special — their differentiating value — and using the most boring, accepted solution for everything else.

It’s a rule of thumb that works universally: build what makes you special and buy the rest. But the critical difference is that, in newsrooms, what makes you special is the journalism that software enables, not the software itself.

This creates a particular challenge for newsroom engineering teams. Because the product is journalism rather than a unified software platform, newsrooms often end up with a constellation of disconnected tools, each serving a different newsroom function. At the same time, these teams are typically much smaller than their tech company counterparts.

When you build software, you’re not just signing up to architect and produce it: you’re also on the hook for maintaining it for its entire lifecycle. Every unique software project you build comes with its own maintenance overhead. This is cumulative. If you continuously choose build over buy, you accumulate maintenance overhead until your team is drowning in upkeep with no capacity for anything new.

As a result, most newsroom teams should buy almost everything. The bar for building something new needs to be very high: it has to be something that provides real strategic differentiation.

But understanding what to buy and when to build only works if the organization itself is structured to make those decisions coherently — and many newsrooms aren’t.

Product teams are not helpdesks

Okay, but why are newsrooms saddled with constellations of disconnected software?

In a tech company, there’s a golden triad of teams that work together in tandem: engineering, design, and product. Each of these has a corresponding leader in the C-suite. The result is that technology, product design, and user experience shape company strategy from day one. They’re not afterthoughts once the business model is figured out; the business model rests on them.

Newsrooms rarely have a comparable structure. Technology and product functions — when they exist as distinct roles — lack the strategic authority they’d have at tech companies. Technology is seen as a tactical function that keeps systems running — running the network and keeping the CMS online — rather than a strategic partner that can build competitive advantages.

Strategy, then, comes from elsewhere in the organization, even when it’s inherently technical in nature. Those teams know their own needs, but their understanding is shaped by their own domain expertise, not by engineering principles or emerging technical capabilities. They know what similar newsrooms are doing, but not what’s technically possible.

Without unified platform strategy or technical leadership at the strategic level, technology teams become reactive. Requests come in from every direction: the graphics team needs better publishing tools, investigations wants data analysis capabilities, the audience team needs custom dashboards. Each request arrives independently, and each feels urgent to the stakeholders who need it.

This is the helpdesk trap. Technology teams triage incoming requests and build one-off solutions to immediate problems rather than identifying patterns, creating shared platforms, or asking strategic questions about long-term architecture. Each department gets what they asked for, but the organization accumulates technical debt.

In small, reactive teams juggling fragmented requests, knowledge silos form quickly. Often, by necessity, one engineer owns each custom tool. It’s common for them to be abandoned once that engineer has left the organization.

Each custom tool adds to the constellation, each one deepens the maintenance burden, and the cycle reinforces itself. As overhead grows, teams become more reactive and less able to step back and think strategically about the next decision.

This is why disciplined build vs buy thinking is critical in newsrooms. The default bias is toward building, but the structural constraints mean most teams should buy almost everything, leaving building for projects that yield genuine strategic differentiation that can’t be achieved any other way.

But even perfect build vs buy decisions can’t fully solve the underlying problem. A helpdesk approach to technology results in fragmented strategy and limited innovation, regardless of how efficiently it’s managed. There’s no substitute for making technology a key strategic partner rather than a service function.

To be clear: it’s not that newsrooms need to be tech companies. But every modern newsroom lives and dies on the web, and that web-first thinking needs to be a core part of its strategic DNA. More than that, every newsroom thrives on building trusted relationships with its readers, and technology has the potential to strengthen and empower those relationships.

With all of this in mind, how do we actually make these decisions in practice?

When to build vs buy

Newsrooms should never build commodity technology: things that have been built hundreds of times before. If your approach for authentication, ad serving, etc, isn’t differentiated from the norm, you should buy it.

That means you should almost always buy infrastructure and security (authentication, payments, hosting), standard publishing tools (core CMS, email delivery), analytics, ad serving, business operations tools, and social media management.

Before deciding to build, challenge yourself with these questions. You need a clear yes to all of them:

• Does this enable journalism we literally cannot produce any other way?
• Have we genuinely evaluated vendor options, not just assumed they won’t work?
• Can we commit real engineering time to maintain this for 3-5 years, even after the original builders leave?
• Is this tied to our specific editorial differentiation, not just “nice to have”?
• Will multiple teams benefit, or is this solving one group’s problem?

If you answered yes to all of these, dig deeper with these practical questions:

• Have we looked for vendor solutions that meet our newsroom-specific needs, including legal requirements around data retention, subpoena response, and source protection?
• Could we buy something close and either configure it or adapt our workflow slightly?
• Could we contribute to an open source project instead of building from scratch?
• What’s the true cost including 3-5 years of maintenance versus vendor pricing?
• What are we not building if we commit resources to this?

And then, when you’re calculating your build costs, include:

• Initial development (multiply your estimate by 2-3x)
• Ongoing maintenance (at least 20% of engineering time annually)
• Documentation and knowledge transfer
• Opportunity cost of other features
• Risk cost when original builders leave

Compare these costs to the cost of buying a solution over 3-5 years, not just the first year. Usually you’ll find that buying is cheaper if you’re honest about maintenance.

When in doubt, buy. Building is a one-way commitment: once people depend on your custom tool, you can’t easily abandon it. If you’re careful about buying, it’s reversible. You can always build later if vendors truly don’t work. Start with the assumption that you’ll buy.

In practice, the smartest teams wind up doing both. They buy the stable foundations — CMSs, data stores, analytics — and build the connective tissue that ties them to the newsroom’s unique workflows. Those small bridges and integrations are where differentiation lives.

As modular SaaS, open APIs, and generative tools evolve, the line between building and buying will keep blurring. The real question won’t be “should we own this code?” but “which capabilities do we want to own?” The newsrooms that answer that clearly will adapt fastest to whatever comes next.

Software you buy doesn’t need to lock you in

Even if you’re buying software from a vendor, you don’t need to be locked into their services.

Open source software offers a middle path between vendor lock-in and building everything yourself. When you use open source software, you get the benefits of buying — someone else handles core development — without surrendering control. The code is yours to inspect, modify, or move if needed.

That last piece — moving — is the most important. The sweet spot is when a project team provides its own commercial services: you buy their support, use their hosting, and usually enjoy the best possible managed version of their product. But if it all goes south — the CEO has become a megalomaniac, the company has been acquired and is undertaking a hard pivot — you don’t need to find another product. You can take your data and the underlying code and run it somewhere else. There are usually a handful of other managed services to choose from.

In other words, treat open source as buy with an escape hatch, not free building blocks. Adopting an open source project and hosting it yourself should be considered a build decision; you’ll pay in maintenance. Obtaining commercial services for software with an open core should be considered a buy decision.

Many newsrooms have succeeded with open source publishing platforms (WordPress, Ghost), specialized journalism tools (DocumentCloud), or analytics solutions. The key is choosing projects with active communities, regular updates, and a great commercial support structure.

Helpdesks don’t build the future

Getting your build vs buy balance right is how you achieve table stakes: stable infrastructure, reliable publishing, sustainable engineering. But that sets you up for today. In order for any business to future-proof itself, it needs to make a bet on what the future will look like and build for that.

The future of journalism will be shaped by the newsrooms that treat technology as a strategic partner, not a support function.

This means bringing technology leadership into strategic planning conversations, not just implementation meetings. It means asking, “what could we do that we’re not considering?” alongside “can you build this?” It means looking for patterns across the disparate requests your team receives and asking whether there’s a platform or capability that could serve multiple needs. It means looking outside the journalism industry to learn from innovation and nascent trends elsewhere.

When technology leads strategically, it expands what’s possible. It builds storytelling formats that couldn’t exist before, finds new ways to earn reader trust, anticipates future challenges, and helps newsrooms reach people who’ve been left out of traditional coverage.

The build vs buy framework helps you avoid technical debt, but can’t prevent all of it. More than that, though, building the future of journalism depends on treating the people who understand what’s technically possible, and who see the trends ahead, as essential partners in defining what journalism can become.

The future of journalism won’t be defined by who builds the best CMS or analytics dashboard. It’ll be defined by who uses technology to deepen trust, reach new audiences, and tell stories that couldn’t exist before.

That requires engineering as imagination, not just implementation.

Buy stability. Build possibility.