The Old Vertical SaaS Moat Is Dead. Where Are the New Moats Now?

Town CEO Jean-Denis Greze on the software moat that just died, why his team ships a major feature every week, and the parts of a product that should never move fast. An audio version of this interview is available on Spotify.

Three Takeaways

• The moat that defined the last 15 years of software is gone. For almost two decades, being first to a product bought you a head start. But when your competitor can copy a product in weeks instead of years, that head start is worth almost nothing.

• Speed is now table stakes, and you get it by constraining yourself. Town ships one major feature a week and has never taken longer than three weeks on anything in the company's history.

• But speed is a calibration, not a maximum. The right velocity for your team isn't "as fast as possible everywhere."

Introduction

One of the loudest narratives in the AI-and-software story right now is the “SaaSpocalypse”: the moats that protected software businesses are eroding.

Jean-Denis Greze was CTO at Plaid and a former engineering leader at Dropbox. Now, as CEO and Mayor of Town, Greze is candid that what made software defensible for two decades is going away. But he doesn't treat that as a reason to despair. He treats it as a reason to do two things: get into the arena and find out what the new moats are, and get ruthless about speed, but only where it matters. 

SaaS Is Losing its Old Moats

To understand why Greze says SaaS companies’ old moats are gone, it helps to remember how many companies used to win. For the last 15 years, you could start a company, spend a year building your first product, and find product-market fit. Your competitors would notice and start to copy you, but it would take about a year for them to finally catch up. 

At that point, you’d had a whole year or so of user input and already pulled ahead. In most categories of vertical software, you’d see two or three companies come out on top who simply stayed there because the venture math stopped working for anyone else. No investor wants to fund the fifth entrant when it would cost a fortune just to reach a roadmap industry leaders already left behind.

That entire dynamic, Greze says, is dead. The reason is simple: it no longer takes a year for your competitors to replicate your product. It now only takes weeks, perhaps months if you're lucky. The first mover advantage that defined SaaS for almost two decades has now shrunk considerably, if it exists at all anymore.

But, Greze says, nobody knows what the new moats are because they haven’t appeared yet. The only reliable way to find out what they are is to build and get product and market signals as early as you can.

Manufacturing Velocity

If the old way to win is gone, the new baseline is obvious: move faster than the competitors looking to replicate your product. 

Greze uses his company, Town, as an example. The Town team built a mobile app in two weeks that could already serve as a real MVP. It was secure and already boasted five of the ten features users wanted most.

So how does a team of 11 ship so quickly and consistently? Greze points to three reasons.

Benchmarking against top teams

The first is that Town frequently benchmarks against the fastest teams they can find. Greze treats the group inside Anthropic shipping Claude Code as the gold standard, alongside a handful of companies like Ramp. Every week he asks himself a simple question: is Town within 10 to 20% of those companies, better or worse? If the answer is no, he thinks that's worth a conversation with the team.

Constant conversation around AI effectiveness

The second is constantly talking about how they use AI. The team trades notes over lunch, compares approaches with friends at labs and at other fast-moving companies, and treats AI-driven development as an ongoing investigation rather than a solved problem. Crucially, there isn't a mandate to vibe code everything. Often, the conclusion is the opposite: that a part of the product has had too much vibe coding and the time has come to rebuild it properly.

Moving at clock speed

The third is to consistently move at clock speed. Town commits to shipping one large feature every week, and usually knows what the next two or three will be. Nothing the company has ever shipped has taken longer than three weeks. Greze’s belief is that constraints which feel impossible are exactly what make people creative, and that AI has made it dramatically easier to test a hypothesis about how to move faster. Put the constraint in place, he says, and people almost always find a way through.

Not Everyone and Everything Should Move at Maximum Velocity

Here is where Greze parts ways with the loudest version of the go-fast gospel. Velocity, he says, is not a single setting you crank to maximum across the whole company. How fast your team needs to ship depends on two things: what part of the product you're touching, and who your competitors are.

Take his own product. Town's web surface moves fast. Its iOS app moves noticeably slower, and for reasons that have nothing to do with effort. There's less world-class open-source iOS code for models to have learned from, so they're simply less fluent there. And the cost of a mistake is higher, because a broken mobile build ships out into the world and has to be pulled back through forced upgrades. So Town is more careful with iOS, and accepts a smaller speedup in exchange.

Then there are the parts of the product where speed is the wrong goal entirely. Storage. Key rotation. The systems that handle data privacy and security, where Greze knows he cannot afford to be wrong. "We're not vibe coding key rotation," he says. There is no single software development lifecycle that applies everywhere inside one company.

The deeper point is about competitive sets, and it's a lesson he traces back to Plaid. If you're building under the same constraints or in direct competition with Anthropic, then you'd better move faster than Anthropic. But if you're in healthcare, the constraints on what you can get right and wrong are completely different, and your speed should look completely different as a result. Knowing who you're competing against tells you how fast you need to be, and where. Greze knows Town's competitive set, which is exactly why he knows which parts of his product can afford to sprint and which absolutely cannot.

What This Means for Leaders

The practical takeaway is a reframe of the velocity debate. If your database team isn't moving at light speed, Greze says, that's probably correct; you don't want them to be, and a 10x speedup there would be reckless. But if you're running an early-stage company doing a lot of frontend and product work, where your API endpoints aren't even changing underneath you, and you haven't found a way to be multiples faster than you were two years ago, you are going to lose. Same technology, opposite conclusions, and the entire difference is context.

So the biggest challenge for an engineering leader isn't how to keep accelerating their team's velocity. Rather, it's about making a series of honest calls. Which parts of the product can sprint, and which have to be slow and correct? Who are you actually competing against, and what does their pace demand of you.

Greze is the first to admit he hasn't figured all of this out. Town is still in its first inning, iand he's candid that everyone is still experimenting with how to use these tools well. The leaders who do best, he says, are the ones who treat speed as something to be calibrated deliberately, part by part, rather than a race to be won at a single pace. The question was never really how fast you can move. It's how fast each part of what you're building actually needs to.

For more episodes of Stack Trace, subscribe to Span's YouTube channel or to the Stack Trace podcast on Spotify.