Linear #173: Legacy SaaS Mapped the Workflows. With AI, We Need To Map the Work
One vSaaS breakdown. One biz story. One 'how to'. In your inbox once a week.
Today’s newsletter is sponsored by Xplor Pay. Embedded payments shouldn’t slow your growth. Xplor Pay Flex Framework helps vertical SaaS platforms choose the right model, adapt over time, and scale with confidence.
Shaped by lessons from decades of building and scaling 20+ SaaS platforms, it turns payments into a true growth lever. Read the guide to see how top platforms get it right. Read Now.
This week I went back and looked at one of my favorite old vertical SaaS visuals: the Toast graphic from their S-1.
It still hits…
Not because it’s polished. Not because it says “platform.” And not because it has a bunch of product boxes hanging off a restaurant. It hits because it captures something most software companies miss:
A vertical business is not a collection of features. It’s a collection of workflows.
That’s what Toast understood.
They didn’t just map restaurant software. They mapped the restaurant itself.
They mapped the way guests move through the space. The way staff move through shifts. The way money moves through the register. The way orders move through the kitchen. The way labor, inventory, reservations, reporting, loyalty, payroll, and payments all connect into one living system.
That’s why the visual has held up so well.
It wasn’t really a product diagram.
It was an operating diagram.
And I think that matters even more now than it did back then, because if we’re being honest, most vertical SaaS founders are still doing the old exercise. They’re still mapping the business as software categories. POS. Payroll. Scheduling. CRM. Analytics. Reporting. Maybe a little fintech layered in.
But AI changes the exercise.
Not a little.
Completely.
Because old software mostly helped you record work.
AI-native software can increasingly help you do the work.
That means the map itself has to change…
Toast didn’t just sell restaurant software.
They mapped the whole restaurant.
The easiest way to misunderstand Toast is to say they built restaurant POS software.
That’s true in the same way that saying Amazon is an online bookstore is true.
It’s technically correct and strategically useless.
What Toast really did was much more important: they took a fragmented, chaotic, deeply operational vertical and mapped it as a connected system. They understood that a restaurant is not just a place where transactions happen. It’s a place where dozens of small workflows collide all day long.
A table gets seated. An order gets modified. A ticket backs up. A shift changes. A supplier is late. A payment fails. A line cook doesn’t show up. A guest leaves a bad review. A manager comps a meal. A server picks up another section. A catering lead comes in. Inventory drops faster than expected. Payroll closes at the end of the week whether you’re ready or not.
That is the business.
And what made Toast so strong is that they didn’t look at those as isolated problems. They looked at them as parts of the same operating system.
That’s such a big lesson for vertical SaaS.
The best companies in our world do not start by asking, “What software category can we sell into this industry?”
They start by asking, “How does this business actually run?”
That sounds obvious, but it’s not how most people build.
Most people start with a wedge that looks like a screen. Toast’s insight was that the real wedge was the workflow. Once you understand the workflow, you can keep expanding through it. Once you sit close enough to the operational heartbeat, you get access to more use cases, more data, more trust, and eventually more monetization opportunities.
That’s why companies like Toast become more than software companies. They become the infrastructure layer for the vertical.
And, of course, once you really own the workflow, you don’t just sell software anymore. You start participating in the money movement underneath it. Payments. Capital. Payroll. Financial services. That’s where vertical SaaS got really interesting.
So when I look at that old Toast visual, what I see is not a company that won because it had a better interface.
I see a company that won because it had a better map.
And here’s the question I keep coming back to:
If we were doing that mapping exercise today, in a world where AI can actually interpret, route, recommend, and increasingly act, would we draw the same map?
I don’t think we would.
Not even close…
Old Vertical Software Mapped Workflows
But AI Should Map the Work
This is the real idea.
For the last twenty years or so, most vertical software was built around the same basic logic. Someone opens a screen, enters information, saves it, and then that information sits in a database until someone else needs it later. Maybe it gets turned into a report. Maybe it triggers a basic rule. Maybe it just lives there forever.
That model created an enormous amount of value. It took industries that were running on paper, memory, spreadsheets, and manual coordination and gave them structure. That mattered. It still matters.
But it also created a generation of software that mostly recorded the output of human labor instead of reducing the need for that labor in the first place.
That’s the subtle but important distinction.
The software became very good at storing decisions after a human made them. It was much less good at helping make the decision, moving the decision forward, or resolving the ambiguity that created the work in the first place.
That’s why so much software still feels passive.
It stores. It displays. It reports.
But it doesn’t really orchestrate.
AI changes that.
Now software can take in messy information, figure out what it means, structure it, compare it against context, recommend a next step, and in some cases just do the next step. That’s not a minor product improvement. That’s a different category of software behavior.
Which means if you’re a founder mapping a vertical today, you shouldn’t just be asking where data gets entered.
You should be asking where work begins.
That’s a much more interesting question.
Where does the actual workflow start? Is it an inbound phone call? A voicemail? An email? A PDF invoice? A reservation change? A catering request? A guest complaint? A no-show? A chargeback? A schedule swap? A missing item from a supplier? A manager text at 6:12 a.m. because somebody called out?
That’s the map now.
Not modules. Not menus. Not navigation tabs.
Work.
And if you really follow that thread, the whole architecture of the business starts to look different.
A restaurant, for example, is no longer just POS, payroll, scheduling, inventory, and marketing.
It becomes a chain of workflows.
Demand comes in from all over the place. Some of it is structured, some of it is messy. That demand has to be interpreted, converted, routed, fulfilled, measured, and followed up on. Labor has to flex around it. Inventory has to support it. Payments have to capture it. Exceptions have to get resolved. Managers have to step in only when the situation becomes ambiguous, high-risk, or economically meaningful.
That is a far more AI-native way to see the business.
And this is exactly why I think the “messy inbox” idea David Haber penned is such a strong thinking framework for vertical AI.
Most industries still have some version of this problem: too much unstructured stuff coming in at the top of the funnel, too many humans needed to interpret it, and too many downstream workflows that don’t start until somebody manually turns chaos into structure.
That’s where AI gets really powerful.
Not when it’s bolted onto the end of a workflow as a chat feature.
But when it sits at the beginning of the workflow and turns ambiguity into action.
That’s a very different thing.
And it’s why, if I were redrawing the Toast map for today, I wouldn’t organize it around product modules. I’d organize it around moments of operational gravity.
Where does demand enter the system?
Where does labor get burned?
Where do handoffs happen?
Where does money leak?
Where does a human still spend time interpreting something that software can now reasonably understand?
And maybe most importantly: where should the human still stay in the loop?
Because I don’t think the right AI map is one where everything gets automated. That’s fantasy. The right AI map is one where the software handles the clean, repetitive, high-frequency parts of the workflow and then pushes the weird, high-stakes, low-confidence moments into an exception layer.
That, to me, is the future UI of vertical SaaS.
Not the dashboard.
The exception queue.
A manager does not want another screen full of analytics. They want to know what needs attention right now, what was already handled, what is blocked, and what matters financially.
That’s the new operating system.
And honestly, once you see it that way, it becomes hard to unsee.
Old vertical SaaS mapped where information got entered.
Vertical AI should map where decisions get made, where work gets stuck, and where software can now carry more of the load.
That’s the exercise.
That’s the opportunity.
And I think that’s where the next great vertical companies are going to come from.
How To Re-Do The Exercise in the Age of AI
Part of what pushed me to write this came out of a conversation I had with David Haber, a GP at a16z.
We were talking about old vertical software maps, why some of them were so powerful, and why they now feel incomplete. That conversation sharpened something for me that I had been circling for a while: in the AI era, it is not enough to map the workflows.
You have to map the work.
That sounds like a small distinction, but I think it changes everything.
A workflow is the clean version of the business. It is how the business gets described in a deck, an implementation plan, or a software menu. Orders flow here. Payroll goes there. Scheduling sits over here. Reservations feed into table management. Inventory connects to purchasing. Reporting rolls up on the back end.
That is useful. But it is also sanitized.
Work is messier than workflow.
Work is the manager reading a long email from an angry guest and deciding whether to comp a meal.
Work is someone listening to a voicemail about a catering request and figuring out whether it is real, urgent, and worth following up on.
Work is a back-office employee opening an invoice PDF, checking whether it matches expectations, routing it to the right person, and cleaning up the edge cases.
Work is somebody noticing that a reservation change is going to affect table flow, staffing pressure, and probably ticket times.
Work is somebody acting as the human bridge between a messy real-world event and a structured software system.
That is the piece most old software never really touched.
The old software map showed you where information ended up.
It did not show you how much labor was required to get the information from here to there.
That is why I think the first principle for re-doing the Toast exercise in the age of AI is this:
Don’t just map the workflows — map the work required to keep the workflows moving.
That means asking a different set of questions.
Not just: what are the modules?
But: where is labor being spent on interpretation? Where is labor being spent on coordination? Where is labor being spent on routing, exception handling, follow-up, checking, clarifying, escalating, and cleaning up?
Because that is where AI enters.
If you were doing this for restaurants, you would still want to understand the big functional areas. You would still care about reservations, ordering, kitchen operations, labor, payments, and guest engagement.
But then you would go a level deeper.
You would ask: what does the human actually do inside each of those areas?
What are all the jobs that exist within the company? What are they doing? How much are they paid?
And to go a layer deeper:
Where do they read things?
Where do they listen to things?
Where do they decide what something means?
Where do they move information from one place to another?
Where do they act as the operating glue holding the whole system together?
That is the work map.
And once you have mapped the work, the next question is: what wedge do you use to attack it?
This is where I think David’s framing is especially helpful, because we are not seeing one single AI wedge work across every market. We are seeing a few recurring patterns.
The first is AI services.
This is maybe the most practical wedge because it goes straight at labor. In a lot of vertical industries, the software exists, but humans are still doing all the real work around it. They are checking, correcting, reconciling, interpreting, and pushing the workflow forward manually. So instead of starting with a better interface, AI services starts with a better way to do the work itself.
Camber is a great example of this. Healthcare reimbursement has historically required huge amounts of specialized human effort layered on top of bad systems and fragmented processes. Claims have to be submitted, fixed, chased, and reworked. Entire services businesses grew up around that pain. What Camber does is turn that labor-heavy reimbursement problem into a software problem. That is why the wedge is so strong. They are not just selling a nicer billing tool. They are going after work that used to require armies of people.
And that is a useful lens for rethinking something like the Toast map. In restaurants, a surprising amount of operational drag still looks like services work hiding inside the business. Catering intake. Guest recovery. AP reconciliation. payroll exception handling. Supplier coordination. These are all places where people are still acting like an internal services layer because the software never really absorbed the work.
The second wedge — and I think the most exciting — is the industry-specific GPT.
This is where things start to get really interesting.
Because now you are no longer just automating a step in the workflow.
You are building an intelligence layer for the vertical itself.
That is a much bigger idea.
An industry-specific GPT is not just a chatbot with a little fine-tuning. It is not just generic AI wearing the clothes of a vertical. At its best, it starts to understand the actual language, logic, edge cases, constraints, and judgment patterns of the domain. It behaves less like a feature and more like an emerging operating intelligence for the industry.
OpenEvidence is a great example of this. The reason it is powerful is not that it is “ChatGPT for doctors.” That framing is too shallow. What makes it compelling is that it is becoming a medical intelligence layer grounded in the realities of clinical decision-making. It is useful because it understands the domain well enough to help practitioners reason inside it.
And once you start thinking this way, the workflow map changes dramatically.
Because now the question is not just: where can I automate labor?
The question becomes: where does this industry need a brain?
What would the restaurant equivalent of that look like?
It would not just answer questions about menu items or write a promo email.
It would understand the operating reality of restaurants. It would understand labor pressure, table turns, reservation pacing, kitchen bottlenecks, menu mix, guest recovery, promo strategy, inventory risk, staffing tradeoffs, refund behavior, and the way all of those things interact.
That is a completely different category of software.
At that point, you are not just building around the workflow. You are building a domain-native intelligence layer that can increasingly guide the workflow.
That is why I think this wedge is the most interesting one.
If the AI services wedge helps you do the work, the industry-specific GPT wedge helps you understand the work at a much deeper level than old software ever could.
And in the long run, that may be the more powerful position.
The third wedge is building agents on top of the system of record.
This one is a little more tactical, but it is incredibly important because it acknowledges a simple truth: in many verticals, the incumbent system still has the data gravity.
It may be hated. It may be clunky. But it is embedded. It is where the records live. It is where the workflow officially lands. That means one of the smartest ways to wedge in is not to replace it immediately, but to start from it.
Use the system of record as the foothold. Read from it. Write back to it. Make it smarter. Reduce the labor around it. Turn it from a passive database into something that feels more action-oriented. You essentially build Agents on top of it.
Datagrid is a great example of this pattern. It does not begin by asking the construction company to replace the system of record (IE Procore). It starts from the fact that the CMS is already embedded in the workflow and already the source of truth. The wedge is to capture the conversation, structure the documentation, and make the surrounding workflow dramatically more usable while integrating into the existing record system. That is a very different strategy from trying to rip out the incumbent on day one.
There is a very obvious parallel in restaurant software too. If you were attacking the Toast map this way, you might not begin by replacing Toast or the broader stack. You might start by asking what AI can do when it sits on top of the systems that already exist. Can it absorb the labor around them? Can it turn raw operational data into clear actions? Can it surface exceptions instead of forcing operators to dig? Can it make the existing stack feel much more intelligent without forcing a painful rip-and-replace?
That is wedge number three.
And the important thing is that these wedges are not mutually exclusive. In fact, the best companies will probably move through them over time.
They may start with AI services, because that is where the urgency and labor budget live.
Then they may deepen into an industry-specific GPT, because that is where the real intelligence advantage gets built.
Then they may sit on top of — or increasingly absorb — the system of record, because that is where the workflow gravity and defensibility live.
That progression feels right to me.
And it also gives us a much better way to redo the original Toast exercise.
The old version of the exercise asked: what are all the categories make up the restaurant?
The new version should ask: where is the labor, what kind of work is being done, how much does it cost, and what wedge is best suited to attack it?
Is this work best attacked as an AI service, because humans are still doing it manually at scale?
Is it a place where an industry-specific GPT can become the intelligence layer for the vertical?
Or is it best attacked by building an agent on top of the system of record, because the workflow gravity is already there and the wedge is to make it dramatically more useful?
That is the strategic map I would want to draw now.
Not just where the workflows are.
But where the work is.
How the work gets done.
And what kind of AI wedge can most naturally absorb it.
That feels like the real AI-era version of the Toast map.
And I think founders who do this well are not going to build a handful of AI features around old vertical software.
They are going to build the new operating layer for the vertical itself.
Do me a solid and forward to a friend :-)