Viafoura | Build vs Buy: Pricing in the Whole Iceberg

AI has made building software cheaper than ever. But building software and owning software are two very different things.

By: Mark Zohar

Let me start by declaring my biases. I’m the CEO of Viafoura. We deliver managed community products and services through CommunityOS to over one thousand media brands. So yes, I have a horse in this race.

That said, I’ll argue against my own interest for a moment. We’re living in an era where build vs. buy is a legitimate strategic question. One every publisher and media brand should be asking.

The thinking goes like this: “I have access to AI tools. I can now build features and products I used to buy from a technology partner.”

That’s true. You probably can. In some cases, you probably should.

But a fundamental distinction gets lost in the excitement:

Building software is cheap now. Owning it isn’t.

Take community. Any publisher can build a comment box. Very few can build, staff, secure and govern a community. AI made the comment box cheap. It didn’t make the community cheap.

The Build vs. Buy Iceberg: What Lives Below the Waterline

Think of software as an iceberg. The features you can see, demo and build are the tip. They’re visible. They’re exciting. And increasingly, they’re easy to create.

The real costs live below the waterline:

Governance: who owns the product, makes decisions and manages risk.
Compliance: privacy, data protection and evolving legal requirements.
Security: vulnerability management, access controls, audits and incident response.
Reliability: infrastructure, monitoring, uptime and disaster recovery.
Mobile development: compatibility across devices, operating systems and app releases.
Feature innovation: keeping pace with changing user expectations.
Continuous improvement: performance, accessibility and usability.
Data integrity: keeping data accurate, accessible and secure.
Technical debt: the accumulated cost of shortcuts, aging architecture and dependencies.

None of it is glamorous. All of it is essential. And unlike the initial build, it never stops costing money.

These costs also multiply. Consider a single GDPR privacy erasure request. It has to work across every product the user touched. If your comments, live Q&A and chat each have their own database and moderation tool, every obligation gets implemented three times. Then maintained three times. Then updated three times when the regulation changes.

That’s where total cost of ownership (TCO) actually sits.

Three Tests Before You Build

Before you calculate a single cost, an internal build should clear three tests.

Is it core to your competitive advantage? Not something you need. Something that makes you meaningfully better than your competitors. If it doesn’t differentiate you, why build it?
Can you build something best in class? Not good enough. Best in class. And remember, you’re not competing against a static product. You’re competing against a provider that invests in it every day. If you can’t outperform what the market already offers, buy or partner.
Is it worth what you’ll give up? For publishers and media brands, the core business is content: creating it, distributing it, monetizing it and building direct audience relationships around it. Every engineer, dollar and leadership hour spent on software is one not spent there.

If your build clears all three, run the numbers.

Calculate the Real Total Cost of Ownership

Most build vs. buy comparisons underestimate the cost of building in-house because they only price version one. A real TCO covers three categories.

Initial development: engineering, product, UX, infrastructure, integrations, QA and launch. The easiest to estimate, though internal projects routinely run over budget.
Ongoing ownership: maintenance, hosting, support, bug fixes, security patches, compliance, upgrades and technical debt, plus the people and processes to keep it all running. Not for six months. For as long as the product exists.
Opportunity cost: the initiatives that won’t happen, and the value you won’t capture while you wait to launch.

Most build cases stop at the first category. It’s usually the smallest.

Congratulations, You’re Now a Software Company

Here’s how it usually plays out. The in-house comment section looks fine until the newsroom asks for Live Q&As or polls on election night. That’s when the team discovers it built a feature, not a foundation. Each new capability needs its own moderation, its own login and its own data pipeline. Every request becomes another build.

When you build and own a product, you take on the responsibilities of a software company. That means recruiting, developing and retaining technical talent. And for community, it means people beyond engineering. Who moderates at 2 a.m. on election night? A round-the-clock moderation operation alone can take 8 to 12 people.

You can’t depend indefinitely on the two or three engineers who built version one. When they leave, who understands the architecture? Who fixes the bugs? Who maintains the integrations? Who builds what’s next?

Software companies run continuous talent pipelines because they have to. If you own the software, you’ll need one too, staffed by people whose expertise sits outside your core business.

Technical Debt: The Interest on Every Shortcut

Every shortcut you take to ship version one becomes interest you pay later. And it compounds.

Browsers change. Mobile operating systems evolve. APIs get deprecated. Vulnerabilities emerge. Regulations shift. The code that worked at launch slowly stops fitting the world around it, and every new feature gets harder to build on top of the old ones.

Eventually you face an expensive choice: pay down the debt or rebuild.

SaaS providers carry technical debt too. The difference is they spread the cost across hundreds or thousands of customers. Build in-house and you carry it alone.

The Cost of Being Out of Market

Here’s a number that rarely makes the spreadsheet: what does it cost to wait?

How long will your build take? Six months? A year? And what happens when it runs late, as internal builds usually do?

During that time, you’re not generating audience engagement, converting registrations and subscriptions, collecting first-party data, earning revenue or gathering insights that could shape your content strategy. Competitors aren’t waiting. And if you’re replacing an existing solution, you may be paying for the old one while funding the new one.

A proven SaaS solution can often be live in weeks. Compare the value you’d capture in month one with the value you’d finally start capturing in month nine. That gap belongs in your TCO.

Time to market isn’t a project management metric. It’s an economic one.

The Value You Can’t Easily Build: Experience at Scale

Some value never fits in a spreadsheet. Expertise is one of them.

When you partner with a strong SaaS provider, you’re not just buying software. You’re buying everything they’ve learned implementing, operating and optimizing it across hundreds or thousands of customers. What works. What fails. What looks promising but rarely performs.

That experience shows up in product design, best practices, advisory services, customer success and teams focused on measurable results. Not shipping features. Delivering outcomes.

You can build the code. It’s much harder to replicate the pattern recognition that comes from a thousand implementations.

When Building Is the Right Decision

None of this means publishers and media brands should never build. A from-scratch build can make sense when:

The capability is your core product, not a feature.
You already run the permanent teams it requires, like trust and safety or compliance.
You have requirements no vendor can meet, after testing their APIs, not before.
You’re willing to fund it as a permanent cost center, not a project.

If that’s you, and the full TCO still makes sense, build it.

For everyone else, there’s a third option: build the experience, not the infrastructure. APIs and SDKs let your team create fully bespoke experiences within your own design system, while a technology partner handles the infrastructure, moderation, identity, compliance and data underneath. That might be an app-native community, a newsletter-linked discussion, an election hub, or community woven into video, podcasts and live coverage, all running on one identity and one data layer. You keep control of the user experience without building and maintaining the entire stack.

Full disclosure: this is the approach we’ve taken at Viafoura, specifically to give media brands more flexibility, whether they’re building communities around markets, sports or other high-engagement content. For many, it’s the best balance of differentiation, control, speed and cost.

The Bottom Line: Price the Whole Iceberg

AI has changed the economics of building software. It hasn’t changed the economics of owning it.

Building something quickly doesn’t mean you can operate it efficiently, maintain it indefinitely or improve it competitively. And it doesn’t mean building is the best use of your resources.

Build what differentiates you. Buy what doesn’t.

So before you commit, run the three tests. Then price the full cost: initial development, ongoing ownership, opportunity cost and the rebuild that may follow. Not just the tip. The whole iceberg.

And ask one last question: who’ll be maintaining it three years from now?

If you’re weighing this decision, we’ve put together a detailed build vs. buy guide, including a TCO framework you can tune to your own numbers. Contact us at sales@viafoura.com to receive a copy of the guide.