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.

Three Takeaways

• The moat that defined the last 15 years of software is gone. For two decades, being first to a product bought you a head start that compounded: by the time competitors caught up, you had another year of development and user input on them. But when you can copy a product in weeks instead of years, that head start is worth almost nothing. The advantages that remain, like distribution and network effects, are real but still being discovered, and the only way to find them is to keep building.

• 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. The hard clock speed isn't for show. It's a forcing function that pushes a small team to find creative ways to get there, backed by two habits: benchmarking against the fastest teams in the industry, and talking constantly about what's working and what isn't.

• But speed is a calibration, not a maximum. The right velocity for your team isn't "as fast as possible everywhere." It's set by your competitive set and by which part of the product you're touching. A front-end startup that hasn't found a way to move multiples faster will lose. A team rotating encryption keys, however, should move at a more deliberate pace.

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, anyone can clone your product in weeks, and a startup has no business competing with the big platforms and the model providers who can do everything it does and more.

So where does that leave businesses today? And how do you build products in a world where it feels like velocity is everything?

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 where it matters. 

‘SaaSpocalyse’ is Here, Where are the New 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, so you’d 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 you. It now only takes weeks, perhaps months, if you’re lucky. The first mover advantage that defined the SaaS for almost two decades has now shrunk considerably, if it exists at all.

Greze is incredibly honest about what it means for an engineering leader like him who used to benefit from two things: there weren’t enough software engineers to go around, and even once you'd built something, it took a long time for anyone to copy it. Both tailwinds are fading and the advantage he’s used to is going away.

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.

So what will survive?

Manufacturing Velocity

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

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 most wanted. This is a far cry from building a mobile app from scratch not too many years ago, which could take about six months, and the review process to get that app live in an app store took even longer than it took teams to build the app itself.

Greze breaks the speed down into three things. The first is benchmarking against the fastest teams he can find. He 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.

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.

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.

Keeping the Code Lean Enough to Stay Fast

There's a trap hiding inside all that speed, and Greze is clear-eyed about it. AI writes a lot of code. Ask it to do something and, if you haven't already written the exact helper it needs, it won't go find the right one; it will write its own from scratch. Multiply that across a team and you get a steady stream of green pull requests, all adding code, much of it reinventing things that already exist. The problem isn't just bloat. The next time the model goes looking for the right way to do something, there are now too many ways, and it gets slower and less certain. Complexity you create for yourself is complexity you create for the agent.

The fix he describes is discipline, and some of it gets handed right back to the tools. He points to teams, smaller ones, that have dedicated as much as 20% of their engineers to "red diffs," pull requests whose only job is to continuously remove code. Reduce the complexity, he says, and you speed up the agent the next time around.

He shares a few concrete habits. When planning a feature with a model, he forbids it from writing any interfaces, stubs, or code at all. The moment a model starts naming systems and interfaces, he says, your aperture narrows from wide to focused, when what you actually want is to stay one level of abstraction higher for longer. So he keeps it in plan mode, asks for candidate architectures, and only then moves down. He runs Claude Code's /simplify far earlier than most people would, and has the model produce an explicit plan for what it intends to reuse and abstract before any final code exists. And his favorite technique is almost embarrassingly low-tech: sit down with a cluster of related files and refactor them with the model, asking what's extraneous and how it would write the whole thing again. Do that, he claims, and you can shave 2,000 lines of code almost anywhere in a codebase. Almost nobody spends the time.

The newest habit is about performance. Town started reporting performance metrics directly on pull requests, the same way a team reviews for security or simplicity. The insight is that a model gets better at the things you give it both data about and a hard line to hold. Tell it no page load can exceed 200 milliseconds, give it the numbers and a way to run the tests, and it will hit the target.

Not Everything Should Move at the Same Speed

Here is where Greze parts ways with the loudest version of the go-fast gospel. Speed, in his telling, is not a single setting you crank to maximum across the whole company. It's a judgment, and it depends on two things: what part of the product you're touching, and who you're actually competing against.

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, and the line lands precisely because it's obvious once said and ignored so often in practice. There is no single software development lifecycle that applies everywhere inside one company, because different things genuinely need to be done differently.

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 as Anthropic, 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 actually competing with 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 uncomfortable in a useful way. 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 front-end 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 work for a leader isn't to mandate a velocity. It's to make 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 with, and what does their pace demand of yours? And, hardest of all, where is slowness a deliberate choice, and where is it just inertia wearing the costume of caution? Greze is the first to admit he hasn't figured all of this out. Town is 11 people one batter into the first inning, in his words, and he's candid that everyone is still partly flying blind on how to use these tools well. The leaders who do best, on his evidence, 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.