Why AI Made Buying SaaS More Dangerous

Building SaaS used to be hard. Really hard.

Building SaaS meant months of work on authentication systems, scalable databases, and APIs with proper documentation, rate limiting, and idempotency. You needed compliance frameworks, security audits, billing systems, payment processing, invoice generation, admin dashboards, and support tools. And that was just some of the infrastructure, before you’d built a single feature of your actual product. Only founders serious about the long haul survived this technical gauntlet.

AI broke that filter.

The Old SaaS Landscape

For twenty years, building enterprise software required serious technical chops and serious determination. You couldn’t just wake up one morning and decide to compete with Salesforce. The barriers were real:

• Complex authentication and authorization systems
• Scalable database architecture
• Robust API design
• Cross-browser compatibility (remember IE6?)
• Infrastructure that could handle growth

These weren’t just technical hurdles. They were quality signals. If a founder pushed through months of complex implementations, database migrations, and scaling challenges, they probably had the resilience to handle customer support, product pivots, and the inevitable crises that come with running a business.

The difficulty of building SaaS accidentally created a natural selection process for determined founders.

How AI Changed Everything

Today, you can prompt your way to a working SaaS application in hours, not months. AI can generate authentication flows, database schemas, even entire admin panels. The demo looks polished. The features seem comprehensive. The pricing is competitive.

From the outside, it’s nearly impossible to tell the difference between something built by founders who’ve lived the problem for years and something generated by AI over a weekend.

I’m not anti-AI. It’s genuinely revolutionary technology, and founders who don’t leverage it will lose. Some AI-assisted founders will build incredible products. But removing technical barriers comes with a side-effect people should understand: we can no longer easily identify who has the depth to succeed long-term.

The Quality Filter We Lost

Here’s what most people miss about the “hard to build” era. The difficulty wasn’t a bug, it was a feature. When building SaaS required months of grinding through complex technical problems, only founders with real determination made it to market.

Think about what it took to build a proper authentication system before AI:

• Understanding OAuth 2.0 flows
• Implementing secure token storage
• Handling edge cases and error states
• Making it simple enough for non-technical users
• Planning for enterprise SSO requirements

Building a proper authentication system wasn’t just about coding ability. It required long-term thinking, attention to detail, and the patience to solve problems that didn’t have Stack Overflow answers. As Ben Horowitz writes in “The Hard Thing About Hard Things,” building a startup is fundamentally about dealing with constant fires and challenges that have no clear solutions. Founders who survived the technical gauntlet had demonstrated something valuable: they could stick with hard problems until they were properly solved.

Now? AI can generate an OAuth implementation in minutes… even for a non-programmer. I understand the ins and outs of OAuth because I’ve done it pre-AI countless times. But we can no longer assume the same for others. And eventually, will fewer and fewer developers have this experience? I personally would feel much better knowing that the development team behind the product my SaaS relies on will rise to the occasion in a firefight.

Why This Makes Buying Riskier

When evaluating SaaS vendors, buyers used to have an implicit quality signal: if the product existed and worked reasonably well, the team behind it had proven they could handle complex challenges. That assumption no longer holds.

Today’s market is flooded with products from founders who haven’t been stress tested by complexity. They might be capable, but we don’t know yet. They haven’t had to debug a production outage at 2 AM, migrate customer data without downtime, rebuild a core system that doesn’t scale, or make architectural decisions that impact every customer.

The real risk isn’t that AI-built software is bad. The risk is that you can’t identify who has the depth to support you long-term. Some founders will rise to challenges as they emerge. Others will abandon ship for the next shiny idea when things get tough.

Red Flags in the AI Era

So how do you evaluate SaaS vendors when technical barriers no longer filter for quality? Here are some warning signs I’ve learned to watch for:

Timeline red flags

• Launched complex features suspiciously fast
• No evidence of iteration or refinement over time
• Feature announcements that feel like AI demo showcases

Technical depth signals

• Can they explain their architectural decisions and tradeoffs?
• Do they discuss edge cases and error handling?
• Have they thought through enterprise requirements beyond the basic demo?

Founder commitment indicators

• Track record of seeing projects through to completion
• Deep understanding of the problem space (not just the solution)
• Realistic timelines and honest communication about challenges

The adaptability test

• How do they handle requirements that don’t fit their standard demo?
• Can they think on their feet when you describe unique use cases?
• Do they have real processes for supporting enterprise customers?

What Good SaaS Still Requires

Despite what AI evangelists might tell you, building great enterprise software still requires the same fundamental qualities it always has:

Deep problem understanding. AI can generate code, but it can’t decide what problems are worth solving or how to prioritize competing user needs.

Long-term architectural thinking. The decisions that determine whether software scales gracefully can’t be automated. They require experience, judgment, and often uncomfortable tradeoffs between short-term convenience and long-term flexibility.

User experience design that accounts for complexity. Making powerful software feel simple is an art form. It requires understanding both the technical constraints and the human psychology of your users.

Commitment to customer success. When things go wrong (and they will), you need founders who will dig in and solve problems rather than move on to the next project.

Let me give you a concrete example. We recently spent months perfecting our third-party connector framework. From the outside, it might look like something AI could have generated quickly. In reality, it required careful design to create something robust enough for developers but simple enough for non-technical users.

We made conscious tradeoffs between power and simplicity. We built abstractions that hid complexity without limiting functionality. We planned for enterprise requirements that most of our current customers don’t need yet. These decisions came from understanding our users’ real needs and making careful tradeoffs. The type of product thinking that goes beyond what AI can generate.

The New Decision Framework

In this new landscape, the old “build vs. buy” calculation needs updating. The traditional factors still matter (cost, timeline, existing resources, team capacity), but you now need additional signals to evaluate vendor quality.

Here’s what I’ve added to my decision framework:

When to buy (new considerations)

• The vendor demonstrates deep problem understanding
• They can explain their architectural decisions clearly
• They have a track record of iterating based on customer feedback
• Their solution handles edge cases you haven’t thought of yet

When to build (new considerations)

• You have strong architectural foundations already
• You understand the full scope of the problem you’re solving
• You’re prepared for the long-term maintenance burden
• You have team members who’ve built similar systems before

Questions to ask potential vendors

• What was the hardest technical decision you made building this?
• How do you handle [specific edge case relevant to your use case]?
• What would you rebuild if you started over today?
• How do you plan to evolve the product as requirements change?

The founders who can answer these questions thoughtfully are probably worth betting on. The ones who deflect to AI capabilities or surface-level features might not stick around when things get complicated.

Looking Forward

The AI revolution isn’t slowing down. If anything, building software will get even easier. Voice-to-code, visual programming, and AI agents that can ship entire features are already here.

This means the quality filter problem will only intensify. In a world where anyone can build software that looks professional, learning to identify founders with real depth becomes critical.

The companies worth betting on won’t be the ones rushing to market with AI-generated features. They’ll be the ones who understand that good software still requires the same judgment, commitment, and deep thinking it always has.

---

What signals do you use to evaluate SaaS vendor quality? I’d love to hear your thoughts—reply on X or shoot me an email.