The Vertical SaaS AI Wedge Is Boring Plumbing, Not AI

The Mistake Everyone Makes Selling Software to Old Industries

Here's something that took me years and a lot of wasted code to learn: in old-school industries, AI is the last layer you build, not the first.

Almost every founder and consultant gets this backwards. They lead with the AI because it demos beautifully and it makes a board go quiet in a good way. You show a model drafting a document or predicting a shortfall, and people lean in. It feels like the future.

But the businesses you're actually selling into don't care about your AI. They care about one thing: the single artifact they need produced, correctly, every time. A schedule with no holes in it. A compliance record that holds up. A clean intake. That's it.

This is what I call the vertical SaaS AI wedge, and most people misunderstand what the wedge actually is. The wedge is not the AI. The wedge is the unglamorous work of ingesting messy real-world data, modeling a domain correctly, and producing the one output that matters to that business. It's boring plumbing. And the incumbents skip it, which is exactly why there's an opening.

I've built more than 15 AI systems now, across my own DTC fashion brand and for clients in industries most software founders avoid. The pattern repeats every single time. The companies that win in these markets aren't the ones with the smartest model. They're the ones who got the deterministic plumbing right and added AI on top as a value-add layer.

In this article I'll walk through three systems I built (anonymized) where AI was deliberately added last. In each case, the real wedge was the boring, correct, deterministic work the existing software vendors refused to do. If you're selling into an old industry, this is the part nobody tells you.

What These Businesses Actually Run On

Before you can build anything, you have to see the truth about how these companies operate. And the truth is messy.

How these businesses actually run vs. imagined process

Group texts and one overloaded person

I worked with a physical-security staffing company that scheduled guards across dozens of posts. I assumed there was a system. There wasn't. The entire operation ran through SMS. A manager would text a group thread, guards would reply, and somehow shifts got covered. When someone called out at 2am, one person, in her head, knew who to call.

That's not an edge case. That's how a huge number of these businesses run. One overloaded person holds the whole operation in their memory, and the company is one resignation away from chaos.

Spreadsheets nobody trusts but everybody uses

At a labor-compliance operation, compliance was tracked in a spreadsheet that was three versions out of date the moment I opened it. Everyone knew it was wrong. Everyone used it anyway, because it was the only thing that existed. At a small law firm's back office, intake was handled by whoever happened to pick up the phone, scribbled on a notepad, and re-typed later (or not).

This is the part most SaaS founders never see, because they build from an imagined process instead of the real one. You cannot model a domain you haven't watched. I always listen before I automate, because the workflow on the whiteboard and the workflow in the group text are two different animals.

This is why so many pitches die in these markets. The founder built clean software for a clean process. The actual process is a group text and a stale spreadsheet. If your product assumes order where there is none, it doesn't fit, and no demo will save it.

The Wedge Is Modeling the Domain, Not the AI

Once you've watched the real workflow, the wedge becomes obvious. It's correctly modeling a messy domain and producing the one artifact the business already needs.

Get the data model right or nothing else matters

For the labor-compliance tool, the artifact was a defensible, completed compliance record. For the staffing company, it was a shift schedule with zero uncovered posts. For the law firm, it was a clean, structured intake.

None of those require AI. They require ingesting messy real-world data (texts, PDFs, a guy's memory, three spreadsheet versions) and structuring it into something true and usable. That structuring is the hard part. It's where the domain knowledge lives.

When I modeled the staffing company's scheduling, I had to encode rules nobody had ever written down. Certain guards can't work certain posts. Overtime thresholds. Required certifications per site. Minimum rest between shifts. That knowledge existed only in one person's head until I forced it into a data model.

The one artifact that matters

Here's the thing competitors miss: the data model and the deterministic logic are the moat. In vertical markets, the moat isn't your algorithm. It's the hard-won domain knowledge encoded in how you structure the data and what rules you enforce.

A competitor can buy the same LLM I use. They cannot easily reconstruct the seventeen edge cases that determine whether a compliance record holds up in an audit. That took me weeks of watching, asking, and being wrong before I got it right.

AI sits on top of this structure. It does not replace it. If the underlying model of the domain is wrong, no amount of AI fixes it. You'll just produce wrong answers faster and with more confidence.

Why AI Gets Added Last (And Where It Goes)

Once the plumbing works, AI becomes the layer that makes the product feel like magic. But notice the order. The plumbing came first.

AI as accelerant, not foundation

I wrote a whole piece on why AI was the last thing I built, not the first, and it's the most counterintuitive lesson I've learned. AI is the accelerant, not the foundation. It speeds up a human who stays in the loop. It never becomes the system of record on its own.

Examples: alerts, drafting, summarizing

Here's where AI actually went in those three systems.

Where AI plugs in across three real systems

For the staffing company: once the schedule was modeled deterministically, I added an AI-assisted shortfall alert that flagged an uncovered post before it became a 2am emergency. The deterministic engine knew the post was uncovered. The AI layer made the warning feel proactive and human.

For the labor-compliance operation: AI drafted the first pass of a compliance narrative, which a human reviewed and approved. The structured record was already complete and correct. AI just turned it into readable prose faster.

For the law firm: AI summarized a messy phone intake into the structured fields the firm needed. The data model defined the fields. AI filled the gap between a rambling call and clean data.

In every case, a human stays in the loop and the deterministic core owns the truth. The AI layer is the cherry, not the cake. And here's the honest part: if the plumbing is broken, AI just produces confident garbage faster. I've seen it happen. A bad data model plus a good LLM is a more convincing way to be wrong.

The Law-Change Pivot: Why Deterministic Plumbing Wins

Here's the moment that proved the whole approach to me.

Law change pivot: deterministic rules vs. retraining a model

A regulation changed in one of these industries. Overnight, the compliance requirements the product enforced were no longer correct. The businesses I served needed the product to reflect the new rules immediately, because being out of compliance is not a "we'll get to it next sprint" problem. It's a liability.

Because the core was deterministic and the domain was modeled explicitly, I updated the rules in hours. I changed the logic, tested it against known cases, and shipped. Done. The new requirement was enforced precisely and predictably.

Now imagine if the compliance logic had lived inside a model. I'd be retraining, gathering examples, validating outputs, and hoping the model "learned" the new rule without breaking three old ones. With no guarantee it actually got it right. That's not a position you want to be in when a client's legal exposure is on the line.

This is the structural argument for why AI belongs on top, not underneath. Regulations, edge cases, and liability demand predictable, auditable behavior. When AI in regulated industries goes wrong, it doesn't fail loudly. It fails confidently. A model that "mostly" gets compliance right is a lawsuit waiting to happen.

The wedge holds precisely because it's boring and correct. Deterministic logic is testable. You can point to a rule and say "this is why the system did that." You cannot do that with a probability distribution. In old industries where someone can get sued, that auditability isn't a nice-to-have. It's the entire value proposition.

How to Tell If You're Building the Wrong Layer First

If you're a founder or operator, here's a gut-check you can run today.

A quick gut-check for founders and operators

Ask yourself these honestly.

Founder gut-check: are you building the wrong layer first?

• Does your pitch lead with AI or with the artifact the customer needs? If the first slide is about your model, you've already lost the room that matters.
• Have you watched the actual workflow, or assumed it? Be honest. Did you sit with the overloaded person, or did you sketch a process you imagined?
• Can your system produce value with the AI turned off? Turn it off. If nothing useful happens, you haven't built the wedge. You've built a demo.
• Is AI the only reason your product works? If so, you don't own the domain. You're renting someone else's model and hoping it stays cheap and accurate.

If any of those land uncomfortably, you're probably building the wrong layer first.

The order that actually works

Here's the sequence I follow every time, across multiple regulated industries:

1. Understand how they really operate. Group texts, stale spreadsheets, the one person who knows everything. Watch it.
2. Model the domain and ingest the messy data. Encode the rules nobody wrote down. This is the hard, unglamorous part.
3. Produce the one artifact deterministically. The schedule, the record, the clean intake. Make it correct and auditable.
4. Add AI to accelerate. Alerts, drafting, summarizing. A human stays in the loop.

I've now done this across six regulated industries this year, and the order never changes. The teams that flip steps one and four build impressive demos that fall apart in production. The teams that respect the order build something that survives contact with reality.

Where I'd Start If This Were Your Business

If this were your business, I'd start by ignoring the AI entirely for a few weeks.

I'd sit with the overloaded person. I'd find the spreadsheet nobody trusts. I'd figure out which single artifact the business cannot live without, and I'd ask why the existing software vendors never bothered to produce it correctly. That's where the durable advantage is. Correctly modeling the domain and owning the one artifact that matters, then layering AI on top to make it feel effortless.

This is slower than leading with AI. It's far less impressive in a demo. You can't put "we deeply understand your compliance edge cases" on a slide and watch a board light up the way they do when a model writes a paragraph in real time.

But the boring version is what actually survives. It survives a law change. It survives the weird edge case that breaks the imagined process. It survives a skeptical operator who's been burned by three vendors that overpromised and underdelivered.

If you're a founder selling into a spreadsheet-and-group-text industry, or a CEO whose vendor keeps demoing AI but can't show you the plumbing underneath, that's exactly the conversation I have all day. Let's talk about where the real wedge is for your specific situation, because it's almost never where people think it is.

Thinking about AI for your business?

If this resonated, let's have a conversation. I do free 30-minute discovery calls where we look at your actual operations and find where AI could move the needle, and just as importantly, where it shouldn't go yet.

Book a Discovery Call