Rob Walling’s latest MicroConf talk, co-written with Einar Vollset, lists 10 ways AI attacks a SaaS business. Attack number one is the obvious one: your customer builds it.

Walling’s framing is the founder’s view. The usual comfort: my customers are hair stylists, they will never vibe code my product. His answer:

They don’t need your 50 features. They only need the three that they use.

— Rob Walling, MicroConf

I have been the customer. Not a hair stylist. A large business looking at enterprise SaaS. This is what the moats looked like from the other side of the table.

The Talk in Brief

Ten attacks, in two buckets:

  • Supply (6): customers, competitors, open source, platforms and agencies can all build your product, or the model absorbs it.
  • Demand (4): your customers go out of business, seats vanish, the thing you manage stops mattering, or an agent replaces the human user.

Walling guesses 10-20% of SaaS companies decline or go to zero. Eight moats still work:

  1. Buyers know and trust you.
  2. You are the system of record.
  3. You are allowed to act.
  4. Nobody checks your work.
  5. A regulator already said yes.
  6. Everyone is already in it.
  7. Every customer makes it smarter.
  8. It is hard to keep running.

It is a good list. It is also written for the vendor. I want to test it from the buyer’s chair.

What We Did

I can’t name the system, the vendors or the business. The shape:

  • We looked at buying. Enterprise SaaS vendors pitched. Building it ourselves was the outsider.
  • A weekend prototype. It ran on our real data. It sat on top of months of analysis, which is why a weekend was enough.
  • One week of iteration. 83 merged PRs. Each review with the business became a list of asks, and each ask became a PR, often the same day.

We chose to build, with a vendor as the fallback.

The weekend was not the work

The weekend prototype is the headline. The months of analysis under it are the reason it worked. An agent can build the screens fast. It can’t tell you which screens the business needs.

The Moats, Tested

Walling’s moats are real. From the buyer’s chair, most of them belonged to us, not the vendor.

  • Features: gone. The vendor had far more than we needed. We needed the few that run the business. Walling is right on this one.
  • System of record: ours. The vendor wanted to be the source of truth. We already were. The integrations stayed our job under any vendor. The hard work was ours either way.
  • Allowed to act: ours. The vendor would recommend. Our existing systems do the acting. That moat sat on our side of the line.
  • Data: ours, and fresher. A vendor works from a copy of our data. We already had the live version.
  • Learning loop: theirs, but not about us. Their models learned from other businesses. Ours learned from ours. Pooled learning helps only when the customers look alike.
  • Trust: real, but not the kind Walling means. Nobody on our side had a career built on recommending the vendor. The trust on offer was different: if it breaks, it is their fault.

Two moats held:

  • Hard to keep running. The real question was never “can you build it?” It was “can you run it?” Fair.
  • Someone to blame. When it fails at 6am, a vendor is a phone number. An internal build is a mirror.

Those two are real. Whether they are worth the vendor’s price is the actual decision.

What the Talk Misses

Walling’s room is small SaaS selling to small businesses. Their customers don’t own much: no data platform, no integration team, no engineers. For them, the vendor’s product is the hard part.

Enterprise SaaS sold to big customers is more exposed than that room. The big customer already owns the system of record, the data and the rails. The vendor sells a layer on top. Before AI, the layer was expensive to build, so the customer rented it. Now the layer is the cheap part.

I wrote in February that buy vs build had flipped. This is the firsthand version, and the lesson is narrower. Code was never the vendor’s moat. The integration was always the customer’s job. What the vendor sells now is a run team and liability.

What This Doesn’t Prove

  • A prototype is not production. Ours is still a prototype. Production is the long part.
  • The team is the risk. The plan needs named people and protected time. Lose them and the vendor is the safer choice.
  • Models: my view, not a bake-off. I think ours fit our business better. Nobody has run them head to head yet.
  • One case. A big business with its own data platform and engineers. A five-person firm has none of that, and Walling’s advice fits them better.

For SaaS Founders

Walling closes with eight questions, one per moat. I would add one from the buyer’s side: does your customer already own the hard part?

If the data, the integrations and the rails are theirs, you are a UI on top of their systems. They can now build that UI in a week. Your moat is whatever is left after that week: your run team, and your willingness to be the one they blame. Your models count only if they beat the customer’s own.

The vendor’s pitch used to be “you can’t build this.” Now it is “you don’t want to own this.” Only one of those still holds.

Related Posts