“The cost of creating software is going down to zero.”
Quite a few people have made hyperbolic statements like this on X lately, and it stood out in particular when the CEO of Klarna said it:
If you’re building, buying, or managing software products right now, there are major implications for that trend.
But I have good news for you.
This isn’t a post about whether AI is overhyped, nor is it a doomer take about jobs disappearing overnight.
Instead, I’m mapping out where I believe the economics of SaaS are actually heading over the next five years, and what it means for the companies being built, the teams building them, and what you should do about it starting today.
Let’s get into it.
Captain Obvious: The Build vs. Buy Equation just Flipped (…but not all the way)
For years, the answer to, “should we build this, or buy a SaaS tool?” was almost always the same: Buy it.
Building takes engineering time you don’t have. It distracts from your core product roadmap. You’ll spend months catching up to what an established tool already does. And maintaining it forever? No thanks.
That calculus just changed.
AI-native teams are already doing this. Not with vibe-coded slop, but with professional internal developers moving ten times faster than before.
Yet, this is the easy part of the equation.
If you’ve never bought a tool before, that’s the best time to vibe code something custom that can grow with you.
Yet, that’s not the only place the Build vs. Buy question is getting re-asked. It’s also happening at large companies as they get hit with massive renewal contracts.
Let’s run through some math for a mid-market company:
A SaaS tool costs your company $100,000 a year, but you are sick of feeling gouged. With AI coding tools, it is now worth building internally. You don’t even need an engineer to be full time dedicated to it, so the ROI math is easy and clear.
But, what if the same tool for the same company only costs you $10,000 a year?
Would you still build it? Probably not.
The overhead, the decision fatigue, and the opportunity cost of engineering time all add up.
There’s a floor in this equation for Build vs. Buy, and that floor matters. That’s an opportunity for new SaaS to disrupt incumbents in ways they stand no chance of competing with.
Wait, won’t build costs go to zero?
The framing I keep coming back to is one Naval Ravikant has talked about for years: decide what your time is worth, and don’t do work that costs less than that rate.
If you’ve decided an hour of your time (or your best engineer’s time) is worth $500, then spending more than half a week building and maintaining a $10k/year SaaS tool to save $10k is already a losing trade. The math doesn’t work.
And that’s why you can’t rebuild your entire tool stack and get rid of all your SaaS. You still have to run your business, which is even harder when there will be many more competitors all doing 10X more, too.
But everything above that new Build vs. Buy floor is now at serious risk.
Companies most exposed are the ones people are already loudest about at renewal time. Complaints about Salesforce, Datadog, and ProCore are all common in their fields. When the pricing pain is that visible, the incentive to replace you just crossed a threshold. All it takes is one scrappy team figuring out the migration, and the floodgates open.
The Mid-Market falls first
Who moves to internally built tools first? Mid-market companies.
They’re big enough to have bills that actually hurt, and scrappy enough to still have some startup DNA to do something about it.
A tool that costs as much as a full-time employee is suddenly a very interesting build-vs-buy calculation when a skilled engineer or PM with AI can replace it in a few weeks.
Meanwhile, selling to SMB will be chaotic, which it always has been. Some small businesses will build, some will buy, and there will be a lot of churn as companies figure out which side of the Build vs. Buy line they’re on (and many go out of business along the way for all kinds of reasons).
Then, Enterprise likely moves slowest. Procurement processes, compliance requirements, vendor risk reviews, and a lot of political fiefdoms to protect, all create drag. But don’t mistake slowest for immune. The pattern is as old as SaaS: startups start small, then grow up into the enterprise. The same thing likely happens here, just faster than it did before.
Interfaces aren’t completely going away, but they’re changing
There’s a version of this argument that goes too far: that interfaces disappear entirely, that everyone just prompts their way through every tool, and that traditional software UI becomes obsolete.
That misses something important.
Your aunt doesn’t want to write prompts. Your plumber doesn’t want to become a product manager. Many companies have little or no software talent on their teams.
AI Planning is a genuine skill, and most people aren’t going to develop it from scratch for every tool they touch. And we all have day jobs and tasks within our core job description, so you can’t spend all of your working hours vibe coding, maintaining, and expanding a custom version of every tool your company uses. At some point the overhead eats you and core progress in your job stops.
So no, interfaces don’t go away completely. Yet, they do evolve.
Logging into a website or app isn’t required.
Sure. In many cases, an agent that simply returns an answer to your question, or alerts you about a real issue is what we all want.
Yet, those are not the only use cases that exist for products, and not the only ways to consume information.
Instead, imagine an agent that doesn’t just return raw data, but delivers instructions for how to display the results to you.
The chart is pre-built. The format is optimized. The display logic is already baked in, because the company behind the agent has done this with a thousand customers before you and knows exactly what the report should look like to help you.
You don’t have to figure it out. You don’t have to spend tokens iterating. You just get the answer in the right format the first time.
That expertise, packaged and delivered as part of the agent, is a legitimate moat and worth paying for.
Remember: Token costs still matter. Until compute is truly free, the company that pre-optimizes output is delivering real value you’d otherwise pay for yourself in time (iterating on your prompts) and tokens (the AI deciding what to display and how to display it cleanly).
Data Moats: Real, But Not Forever
The second part of the Klarna CEO’s argument doesn’t get enough attention.
It’s not just that software gets cheaper to build. It’s that the switching cost that kept you locked into a platform you hated is about to get a lot smaller.
Right now, data moats are real. Migrating years of customer history, usage data, and integrations from one tool to another is painful enough that most companies just don’t do it unless they absolutely have to. That friction protects incumbents even when their product or pricing is objectively worse.
But there are two very different kinds of data moats, and only one of them is actually safe.
Moat #1: The disappearing migration moat
The first kind of data moat is the migration moat. Your Salesforce instance is a mess of outdated records, broken automations, and contradictory data that nobody wants to touch.
That’s not going to be a moat for much longer. Every time AI gets better at navigating systems and organizing and extracting data, switching costs drop further.
Watching my OpenClaw navigate a browser like a human was a preview of what migration looks like when someone builds a serious tool around it. The moat isn’t the data itself. It’s the migration pain. And that pain is a software problem. Software problems get solved by AI.
Moat #2: The durable data-product moat
The second kind of data moat is the much more lasting version: where the data itself is the product. This includes products like proprietary benchmarking data, financial datasets that took years to compile, fraud detection models trained across thousands of companies, etc.
This is data that can’t be scraped nor replicated quickly.
In a world with AI, this is a much more durable moat.
But they still need to evolve to serve the changing landscape. MCPs, APIs, and other interfaces for agents are just as important, even if you have proprietary data. Customers will still want it in new, better, faster, and different way.
The Moat that trumps them all: Network Effects
Yet, even better than a data product’s moat is the classic Network Effects moat.
Slack works, because everyone is already in Slack. The same is true for Linkedin, X, Instagram, Github, and tools with strong developer ecosystems and App Stores. You can’t scrape your way out of that.
As long as the network keeps delivering on its core value, that buys more time than any data lock-in strategy.
The questions every SaaS company should be asking right now:
- If migration pain goes away, what’s left?
- What habits are so embedded that customers wouldn’t want to rip us out?
- What integrations run so deep that switching has a real cost beyond just moving the data?
- If the cost of building integrations drops significantly, do we still have an advantage with our app store/developer ecosystem over competitors?
If you can’t answer these clearly, the moat you think you have may be thinner than you realize.
The Maintenance Spiral You’re Not Accounting For
Brian Balfour of Reforge is right. Coding is getting solved, and that’s going to unleash an enormous amount of building.
But it’s also going to create a new kind of debt that almost nobody is budgeting for.
His advice to build fast, but kill 9 out of 10 things, is exactly right. The problem is that most teams won’t do it.
They’ll build, ship, get a few people using it, and then feel too guilty to kill it. And the things that survive create compounding complexity that nobody planned for.
The day-one math looks great. Month 18 is where it falls apart. You run into problems like:
- You can’t go back and track what you didn’t set up to track six months ago.
- Joey in accounting added something that broke your build and now two other teams are affected.
- The tool you built for one team is now being used by ten, with none of the infrastructure to support that.
- The person who built it left, and was sloppy with their notes and organization of the project, so it’s hard to pick up and maintain without them.
- Conflicting prompts across departments quietly accumulate until you have a stack of tools that technically exist, but that everyone works around rather than with.
This is AI Product Debt. It compounds just like technical debt does, except it’s harder to see coming and even more pressure to ignore it until it’s really bad.
The open question is whether AI eventually becomes self-healing enough that maintenance runs with minimal human input. Maybe. But until that’s real (and super token cost-effective), SaaS products, even delivered in an agent-first model, still have a strong case to make on the basis of reliability and maintainability alone.
Enter the Prompt Architect
The good news is that this also creates a new job that nobody has a title for yet: the Prompt Architect.
They’re not a traditional IT person, nor a software engineer. Instead, they’re someone who speaks fluent prompt, understands enough about how software works to keep things from becoming spaghetti, and serves as the institutional memory for how your internal tools actually function.
This role is going to become surprisingly valuable, especially in companies that go deep on internal builds to replace all their overpriced SaaS.
And it’s a natural landing spot for PMs who invest in their prompt skills now.
But even that role has upper limits. How many internal tools can they build, manage, and expand? 5? 10? 20?
That’s where the question gets back to, “Do we hire another Prompt Architect, or just buy a SaaS to do that?”
Not all SaaS products will be easy and obvious in how to prompt your way to an internally built alternative. And not all verticals have the talent or will want to hire the talent to build it. And it is in those deeply understood niches that SaaS products can survive and thrive.
AI may be able to build anything you can prompt, but you still have to know how to prompt it well.
And you need the prompt correct from the start, not after a major problem where you learn 6 months later you needed a key feature you could have had out of the box.
What the New SaaS Company Looks Like
Here’s the shape of what’s coming: 10X smaller teams charging 10X less, shipping 10-100X more, and moving 10-100X faster than the incumbents they’re replacing.
The new, smaller team size becomes a necessity here.
Giant companies with large headcounts have to charge higher prices to support that team size. Small startups can survive the AI squeeze in the new Build vs. Buy equation, but only by thinking and acting differently than incumbents.
Startups have to be 10X more productive per employee to make up for the 10X lower price they have to charge to win.
And regardless of your company size, this has wide ramifications for your career and your business. Here’s how I’m thinking about what PMs need to do, and the hard conversations every SaaS company needs to be having right now.
What this means now if You’re a PM…
The job of a PM is changing faster than most people want to admit. Here’s what I’d focus on:
1) Your most important skill just changed.
For years, the core PM skill was navigating organizational complexity: getting buy-in, aligning stakeholders, managing up, and getting your engineering team to ship on time. That still matters, but it’s not the majority of the job anymore.
Now, to get the best results, you need to master the ability to prompt well, iterate fast, ship quickly, and close the customer feedback loop faster than anyone else on the market.
If you’re not actively building those skills through side projects, experimentation, and weekly time carved out just to try new things, you’re falling behind.
2) PM was always a polymath role. Embrace it.
The thing that has always made great PMs great is their ability to master a wide range of skills and topics fast. That hasn’t changed.
What has changed is your curriculum.
Some of what you spent years mastering don’t matter anymore, while others (like prompting) are becoming critical. The muscle you need to develop is the same one that got you here: learn fast, stay curious, and keep an eye out for how the world and market is changing.
3) Throw out your playbooks. Write new ones.
The strategies that defined SaaS product management for the last twenty years were built for a specific cost structure and competitive environment. Both of those just changed.
The PMs who win in the next five years will be the ones who treat everything as a hypothesis, experiment aggressively, and listen hard to what the market is actually telling them…not what your old playbook says you should do.
The wild west is uncomfortable. It’s also where the biggest opportunities live. Those that figure this out early won’t just do well, they’ll set the patterns that everyone else copies for the next decade, while helping their companies become outlier winners.
What this means now if you’re building or running a SaaS company
1) Revisit your pricing before the market forces you to.
If the hardest part of your sales process is pricing negotiations, you are probably already getting a wake up call. The new Build vs. Buy math is coming for those with the hardest pricing first.
The only way for you to survive is to get ahead of it. A price cut you choose is a strategy. A price cut the market forces on you is a crisis.
And those pricing changes dictate your company structure; they pay for your engineers, your customer support team, your implementation engineers, and more. If the new world requires you to charge substantially less, you have to figure out how that changes your offering, hiring plans, and team structure.
What are you charging for today that your customers won’t need in an AI-driven world? How can AI make some of your offering 10X cheaper to deliver, or 10X more valuable?
2) The “go upmarket and raise prices” playbook may be broken.
The default SaaS growth motion for over a decade was: start cheap, land in the SMB, expand to mid-market, raise prices, and march toward enterprise and a bell-ringing IPO.
That worked when switching costs were high and building alternatives was expensive, but both of those assumptions are now under serious pressure.
Going upmarket still makes sense in some contexts, but the automatic assumption that you can raise prices substantially as you grow needs to be re-examined carefully. And again, that means being very careful about thinking through your internal cost structure, and how you model headcount.
3) Become a hawk on cost structure.
The benchmark that matters in this pricing compression is revenue per employee.
A decade ago, Google and Facebook’s numbers in this area were considered remarkable, with revenue per employee at $500k-$1mn. Yet, now the hottest AI-native companies today are well past those benchmarks with teams a small fraction of the size.
That’s going to become the standard people measure against.
The surprise won’t be the revenue part of the formula. Instead it will be how many customers you need to serve to get there at compressed prices, because those customers are themselves smaller and paying less.
All of this inverts the old formula: instead of one enterprise paying $500k, you have 500 customers paying $1k. Same top line, completely different cost structure, and team size required to support it profitably.
4) Audit your product’s feature set and roadmap.
No matter if you’re an AI or a human, bloated products are hard to maintain and even harder to use.
If you’ve been adding features because you could, you probably have dead weight slowing down onboarding, generating support load, and muddying your positioning.
Tight beats broad in a world where a small team can build a focused competitor fast. But if you must enter a feature arms race, then being intentional about who your user is (i.e.- a human or an AI/agent) is important. The startup that realizes “only an agent needs that feature” saves a lot of time and effort by never building the UI that an incumbent must maintain forever.
5) Uncover and expand your competitive advantages.
If a small, internal team could replicate 80% of your product in six weeks, what’s the part they can’t that really matters in your deals? Answer that question honestly, now, before the market answers it for you.
Meanwhile, if your customers are getting smaller, more technical, and more capable of self-serving, then high-touch CSM starts looking like expensive, unnecessary overhead. The companies that figure out how to deliver real outcomes through agent-assisted or low-touch success will have a structural cost advantage that compounds over time.
None of these questions are easy, but burying your head in the sand only puts you further behind. Instead, these are the kinds of discussions you need to be having as a team, and consciously working on understanding and experimenting with.
Where This Is Headed
My predictions here are for a five-year horizon, not the next five months. Some of this is already happening. Some of it is 18 months away. Some of it depends on how fast the underlying technology moves and how quickly regulated industries decide they can’t ignore it anymore.
Here’s what I’m watching: industries with low switching costs, internal teams capable of building new tools with AI, and loud pricing complaints will be hit by this first.
Meanwhile, regulated industries, lower tech markets, compliance-heavy environments, and tools with genuine network effects will hold out longer (or have enough time to transition to an AI-first structure without being disrupted).
Yet, even if you’re in one of those safer industries or businesses, that’s not a reason to wait. It’s a reason to take advantage of the time you have to get (and stay) ahead of these changes.
Are you ready?
The tidal wave in this story isn’t aimed at the five-person startup. Scrappy teams with low overhead and fast-moving founders are actually the ones best positioned to take advantage of everything I’ve described here.
The ones in for a world of pain are the 5,000-person companies with humongous cost structures, mature sales motions built on high prices and high switching costs, and organizations that are structurally slow to respond to a market that just changed the rules on them.
For startups, this is one of the best moments in a generation to build.
The tools are better, the cost to compete is lower, and the incumbents are more vulnerable than they’ve been in years. But what it means to be well-positioned looks quite different from the standard SaaS playbook; now you have to consider how you can win with lower prices, smaller teams, faster iteration, stronger focus, and a cost structure built for the AI era.
The key is to skate where the puck is going, because whether this reality hits your market in 5 months or 5 years, the winners will be moving in the same direction to get there.
Thanks to Patrick and Dan for feedback on this post.
For Readers: I’m currently looking for my next Head of Product role at a Series A or B company where I can help build and lead a product team through exactly these kinds of transitions. If that sounds like your situation, I’d love to talk. You can schedule a time to talk here, or find me on Linkedin here.