There’s been plenty of talk about a “SaaS apocalypse,” with AI making people question which software they’ll still need to buy. When I looked at Jason Lemkin’s comparison of SaaS winners and losers, I found myself thinking about the products from a customer’s perspective. With some, I could imagine a team building the part it needed. Others provided services I wouldn’t consider trying to recreate.
Chart: Jason Lemkin / SaaStr, Beyond the SaaSpocalypse: The Winners and Losers of 2026 (So Far), published 4 September 2026. Figures cover 2–4 September, as noted in the chart.
That distinction doesn’t explain the share prices. But it does give a marketing or product team a useful question: would a reasonably technically savvy internal team consider using AI to build the part of our product it needs?
I’d think about that in two parts. How difficult would their version be to create? And how much specialist work would they take on to keep it useful?
The danger zone is a product where both are relatively straightforward. The safer end is where customers depend on technical capabilities, external services or continuing expertise that would be difficult to provide for themselves.
The part the customer actually uses
A customer considering an internal build isn’t trying to recreate your company. They don’t need your full product range, every integration or all the features your largest customers rely on. They need something that does their own job well enough.
Take a simple project tracker. A team wants to record tasks, assign people, set deadlines and see what’s overdue. That’s largely an interface over a database, with rules the team already understands. They might have no interest in the broader capabilities of the platform they’re paying for.
If their process stays reasonably stable, the functionality of that internal tool might serve them for years. Someone still needs to handle security, backups and occasional repairs, but they may have little reason to keep adding features.
That’s the sort of product I’d put closest to the danger zone. A customer can imagine both building it and living with the responsibility afterwards.
What makes the internal version harder?
The work grows as the product takes on more dependencies and responsibilities.
External integrations add something else to look after. A tracker that only stores information entered by the team is one thing. A tool that pulls data from several other systems, keeps records in sync and handles failures is a bigger undertaking. When those systems change, someone has to make sure the connections still work.
Specialist functionality can be difficult to reproduce. Building a straightforward document workflow is a very different job from building a sophisticated editing or processing tool. AI may help a team write the software, but someone still needs to understand the job well enough to know whether the result is correct.
Audit and legal requirements change what counts as working. If the data has to stand up to external scrutiny, displaying the right information is only part of the job. The team may also need reliable records of who changed it, what was approved and how the evidence has been preserved. A convenient internal shortcut can become a much larger responsibility.
External infrastructure can put the service beyond a sensible internal build. I can imagine a team building an application that sends text messages through a service such as Twilio. I wouldn’t expect that team to recreate the telecom connections and delivery service underneath it. Their own application would still need to buy that capability.
These aren’t rigid categories. One product can contain several of them, and two customers can depend on very different parts of it. The useful exercise is to look at what a particular customer’s replacement would actually involve.
Keeping it useful may be the bigger job
The first version doesn’t tell you everything about the commitment.
A basic project tracker can keep applying the same rules for a long time. A tool that gathers information from external sources needs someone to notice when those sources change or the information becomes unreliable. A cybersecurity product has to keep responding to changing threats, which calls for continuing specialist attention.
I’d also ask who will look after it. Could a general developer build something the team can maintain with occasional help? Or would the customer need a highly specialised team continually updating it?
A product can be relatively easy to demonstrate and much harder to keep dependable. If that continuing work is a substantial part of what customers are buying from you, help them understand what you’re taking care of for them.
“Safer” here means harder to replace with an internal build. Customers can still choose a competitor or decide the service isn’t worth the price.
Where does your product sit?
I’d work through this with sales and product colleagues, starting with one customer segment:
- Identify the job customers would bring in-house. Look at what they actually use. What would their own version need, and what would they happily leave out?
- Describe what sits underneath that job. Include integrations, data access, specialist functionality and any audit requirements. Separate genuine dependencies from features that simply make the product bigger.
- Make the continuing work visible. What changes do you handle for customers? How often, and what expertise does it require? Use concrete examples of that work in sales conversations.
- Check whether customers value the difference. If they only need a simple, stable workflow, a smaller offer may fit them better. If they rely on your ongoing technical work, help them understand what they’d have to take responsibility for themselves.
Being technically complex isn’t a positioning strategy by itself. The question is whether that complexity does something your customers need and would find difficult to own. That’s what I’d want to understand before deciding how exposed the product is.