What's Next in Vertical SaaS
After posting my essay about Wall Street and the B2B software stocks tumbling, I came across a few items that pulls on the thread even more, to something forward-looking.
Firstly, my old colleague Shawn Smith had a more nuanced reaction to the story. Smith has been both a customer many times over of Salesforce and a product manager there.
On the customer side, without exception, the sentiment was that Salesforce is an expensive partial solution. There were always gaps in what it could do, which were filled by janky workarounds. In every case, the organization at least considered building an in-house solution which would cover all the bases *and* cost less than the Salesforce contract. I think the threat of AI to Salesforce is very real in this sense. Companies will use it to build their own solutions, but this outcome is probably at least 2-5 years out in many cases because switching costs are real, and contracts are an obstacle.
He is less convinced about something like Adobe where individual preferences around tooling are more of the determining factor. The underlying threat in Smith’s analysis—that companies will build their own solutions—points to a deeper question about which software businesses have real moats. Especially with newer, AI-native upstarts.
My former CEO, ex-ServiceTitan, and now Visiting Partner at Y Combinator, Charlie Warren writing in his brand new Substack:
A simple basket of vertical SaaS stocks — Veeva, Procore, Toast, AppFolio, and Guidewire — outperformed horizontal SaaS names like Salesforce, ServiceNow, CrowdStrike, Datadog, and Snowflake over the last couple weeks. But the results are relative. Vertical SaaS multiples have cratered, too.
So is Vertical SaaS also “over”? My unsatisfactory answer: it depends. That was my view before the sell off, so dear readers, you’ll have to trust me.
Warren continues, saying that we’re entering a “Vertical AI 2.0” phase. He first sets some context about Vertical AI 1.0:
The core trait of Vertical AI 1.0 was not a lack of ambition. It was assuming the model layer with some unique workflows would remain the scarce asset.
Vertical AI 1.0 was model-first, office focused, and constrained to a few industries. Vertical AI 2.0 is data-first, extends beyond the desk, and applies to nearly every industry.
Vertical AI 1.0 began in late ‘23: novel approaches to LLM-friendly industries like legal, healthcare, and finance. Incredible companies and exceptional founders the likes of Ambience/Abridge, Legora/Harvey, and so forth. Many of these companies are and will continue to dominate, despite frenemy competition with model providers. It will be exciting to watch.
But for many of the other companies, their Vertical AI 1.0 strategy appears to have been: piggy back on model updates with maybe some fine tuning as the sole means of product improvements. Free riding is not a dominant (product) strategy. In recent weeks, Anthropic launched a suite of new finance tooling, OpenAI released Healthcare and then Frontier, and so forth.
And what does he mean by Vertical AI 2.0?
Vertical AI 2.0 is broader than before. …Vertical AI 2.0 is about finding where defensibility lives. And defensibility is a moving target across office and non office (i.e., field) workflows.
For inside the office, more defensibility will accrue to markets with an arcane mix of accounting, legal, & regulatory rules and unique access to data. Founders need to have a different product strategy than Vertical AI 1.0. Eli Dukes recently coined the term “Systems of Training” for these kinds of companies…
To put plainly, it’s about the data and not just the raw data. It’s the data recipe. Let’s open up the post by Eli Dukes post about this.
I want to be careful here to define data in a particular way. What I am not suggesting here is that raw data itself is a particularly good moat. As everyone is well aware, interoperability has meant that structured + raw data is leaving and entering systems all the time. The storage of data is not really proprietary nor that valuable for applied AI companies. While someone will continue to own data storage (the systems of record), the data itself is not uniquely valuable to training.
What is valuable is what I’m going to call the data recipe - ie how do agents when looking at a problem or task provided work their way through a problem to an economically valuable result.
Dukes goes on to compare two types of data gathering: expert-generated, e.g., how a doctor self-reports how they make decisions when examining a patient presenting with certain symptoms and with a certain medical history, and data-generated, e.g., code repositories with pull requests and decisioning data on when code was merged into a main branch. Kinda heady and it breaks down like this:
What’s interesting is that the data vendors as a result have begun to verticalize themselves. Rising data vendors now may only focus on finance or law and seek to capture key data from their domain in a couple core formats:
Raw, unadulterated data - There’s a move to buy/license more human generated data directly from end businesses.
Decisioning data: Approaches differ here between full scale expers and ops vs. other approaches using experts to help define what I’m calling the “ontology of the decision” to then help autogenerate rubrics and grading for discrete instantiations of the task
Outcomes data: Attaching outcomes to completed work artifacts often over a longer period of time to give models a verified outcome (and thus verifiable reward).
Dukes’s post ends with this, essentially saying that the data recipe will be worth more than the user experience:
I have a hunch that the companies who model themselves as an applied system for producing the data recipes and decision logic for training models will ultimately accrue far more value than those who model themselves more as product-centric companies focused on the UX around AI for a vertical.
Which brings us to a new post by Duncan Grazier, my colleague at BuildOps and our Chief AI Officer. He first makes a point that debating the exact coding agent, who will come out on top, is the wrong debate to have. It’s like debating Vim vs. Emacs vs. Sublime (or BBEdit!). Or in design, debating Sketch vs. Figma vs. XD. What he’s wondering about is, “Who will be the next GitHub” where all this agent-generated code lives.
Because there is a data decisioning problem.
When I tell Claude Code to “refactor the billing module to support usage-based pricing,” the intent is the real intellectual property. The code it produces is one of many possible implementations. If I re-run the same prompt tomorrow against a better model, I might get structurally different code that fulfills the same intent equally well.
Today, we version control the output. We have no system of record for the chain of intent, context, constraints, and decisions that produced the code. We’re doing the equivalent of version controlling compiled binaries without tracking the source.
Therefore, it’s a data recipe that can be owned in this vertical of coding.
This isn’t prompt logging. It’s a semantic layer that maps business intent → architectural decisions → implementation constraints → generated code, and keeps that mapping alive as systems evolve.
Imagine onboarding a new engineer where instead of reading code comments (which are already out of date), they can trace any module back through the decision chain that produced it. Imagine an agent that doesn’t just read your code but it reads your intent history and understands the “why” before it writes a single line.
There are other comparable ideas out there. Charlie Warren calls is secret finding:
Secrets are the market insights that, when paired with novel technical solutions, can create generational companies. As a founder, finding secrets does not require having worked in said industry a priori but does require having observed, listened, and learned. A lot. This work is painstaking, uncomfortable, and limitless–what Paul Graham famously called a “schlep” in 2012. Not much had changed in the intervening 15 years of schleping: one must take red eye flights, stay in seedy motels, and grapple with contradictory product feedback from (sometimes) ornery users.
