Your Company Is About to Stop Buying SaaS

Three years ago I spent a quarter choosing between Aha and Productboard.

The goal was simple: make the roadmap visible to the whole company.

We picked Productboard. It worked okay.

Neither tool was a perfect fit. Productboard was more customizable, which sometimes made it more confusing. Submitting and triaging requests was never as easy as it should have been. Aha had the better Jira integration, at least in the versions I evaluated, though I’d expect that comparison to have moved since. We traded one set of compromises for another and moved on, because that was the only move available.

Here is what I did not question at the time: whether the whole exercise was worth it.

We spent a quarter and a real budget line to solve “leaders can’t see the roadmap.” And the tool didn’t actually solve it, because the problem was never that the roadmap didn’t exist somewhere. It was that I was asking executives to open another UI to find it. They didn’t. They were never going to.

I bought a destination when what I needed was a delivery.

Today I would not run that evaluation at all. I would build a roadmap view that pushes into the places leaders already spend their day such as Slack, the exec deck, or the weekly email. Not because I’ve become anti-SaaS. Because the math is changing.

The new build math

The build-vs-buy default was tilted hard toward buy, because building was expensive, slow, and required specialized engineers you couldn’t afford.

That’s breaking. AI is collapsing the cost of writing software. A small team with good AI tooling now ships what used to take a much larger one, and maintains it too. The long tail of refactoring, documentation, and dependency work is getting cheaper at the same time.

The old question was: can we afford to build this internally?

The new question is: can we afford not to?

As a PM, I made prioritization calls based on aggregate customer demand. It was a given that I would never get to the edge cases. I used to say that every company considers itself its own special snowflake. The bigger the company, the more convinced it is that its workflow is uniquely its own.

They were mostly right. I just couldn’t do anything about it. Neither could the vendors.

SaaS pricing was built on that gap. The pitch was: your edge cases aren’t worth building for, and you can’t build them yourself, so buy the 80% and adapt. That assumption held for twenty years.

So the SaaS advantage is shrinking on two fronts. Building is getting cheaper. Custom tools are no longer a multi-year investment. And the switching cost of not getting your edge cases has stopped being something you just absorb.

That combination is brutal for anyone selling generic features at a premium. The defensible SaaS will be the ones with network effects, integrations you cannot replicate, or domain expertise you cannot reproduce internally. Everyone else becomes a candidate for replacement.

The objection I’d raise against my own argument

If you build it, there is no vendor SLA. No SOC 2 report to hand your enterprise customer’s security team. Nobody on call at 2am. No patch cadence for the dependency that just got a CVE. And the day the person who built it leaves, you own a system nobody understands.

I work in security. I’ve watched “small internal tool” become “unowned service holding customer data” more than once.

AI is collapsing the cost of writing software. It has barely touched the cost of operating it. You still need someone on call, access reviews, audit evidence, incident response. Anyone telling you self-hosting is now trivial is selling something.

So the real build-vs-buy line isn’t “can we build it.” We can. It’s: what happens to this thing on its worst day, and who answers for it?

Which gives you a usable filter. Build when the tool:

reads from systems you already own, rather than becoming the system of record
doesn’t hold data that would trigger a breach notification
doesn’t sit in a customer-facing path
can be down for a day without anyone getting hurt

Do not try to build your own CRM. Do not build your own identity provider.

But a roadmap view that reads from Jira and posts to Slack? That fails none of those tests. I paid a vendor for years to not solve it.

What this means for product managers

PMs spent the last decade optimizing for shipping speed. We built rituals, fought for headcount, and argued about velocity. Software was 90% plumbing and 10% business logic, and the plumbing set the pace.

When the plumbing gets cheap, the bottleneck moves. It moves to the question you should have been asking all along: what should we be building?

This is where PM has always wanted to live. Most of us couldn’t, because we were drowning in coordination, estimation, and requirement-clarification work that nobody else was going to do.

That work is now automatable. AI is genuinely good at surfacing architectural risk, interrogating vague requirements, and bridging the tool fragmentation problem: your team is on Jira, another is on Linear, someone has Notion, someone has a spreadsheet from 2019. Less time on mechanics. More on judgment.

And the companies that figure this out will have PMs driving it. Not engineering. Not IT. PM is on deck because the call is a product call, not a technical one.

What changes for a product manager’s career

Learn to price a build, not just request one. You’re going to be asked whether a renewal should become two sprints. If you can’t scope it credibly, someone with less context makes that call for you.

Optimize for where the work already happens. My Productboard mistake in one sentence: adoption is the constraint, not features. Every internal tool you greenlight gets judged on whether people have to leave their day to use it.

Build one small thing yourself. Not to become an engineer. To recalibrate. Until you’ve shipped something with AI tooling, your instinct for what’s expensive is three years out of date. Mine was.

The PM who gets good at these will own the next decade.

The PM who keeps arguing about timeline estimates and Jira workflows will be replaced by a junior PM with an AI co-pilot.

What’s the last tool you bought that you’d build today?

Part 2 picks up where this leaves off: the gap between what a PM asks for and what engineering ships.