Back to all articles
Strategy

The SaaS Design Pattern For The AI Era

Anyone can build software with AI now. The opportunity is in the deterministic, auditable systems AI cannot reliably replace.

August 3, 202611 min read
The SaaS Design Pattern For The AI Era

A prospect looked at my software last year and said something that would have been ridiculous three years ago.

"This is nice, but couldn't I just build this myself?"

He wasn't an engineer. He was an accountant with a ChatGPT subscription and a weekend.

Here's the thing. He was half right, and that half is the most important strategic fact in software right now. Anyone can build now. The floor collapsed. What most people miss is that the floor collapsing didn't remove the opportunity. It moved it, and it moved it somewhere very specific.

Let me show you exactly where it moved, using a discovery I made building B2B fintech software, and then give you the design pattern that puts your product on the right side of it.

The gap between working and shippable

Let's be honest about what actually changed, since a lot of people in software are still in denial about it.

Your customer can now describe a workflow in plain English and get something that runs. They can wire up n8n and automate half their week. They can build a Claude skill that does the thing they used to pay someone for. Whether or not you think that counts as software engineering is irrelevant, since they don't care what we call it. It works well enough for them to feel capable, and feeling capable is what changes buying behavior.

Now here's the other half, and I want to be careful here since this is where founders get lazy and smug.

The gap didn't close. It moved.

There's a study worth knowing. Veracode tested more than 100 language models across 80 coding tasks where the model could pick a secure or an insecure way to do the job. The models picked the insecure option 45% of the time. Cross-site scripting alone had an 86% failure rate.

Here's the part that actually matters for your strategy. They ran it again in spring of 2026 on the newest flagship models. Syntax pass rates climbed from about 50% up to 95% over three years, so models got dramatically better at writing code that runs. Security pass rates stayed flat, hovering between 45 and 55% the entire time. Model size barely moved that number.

That's not a bug waiting for the next release. That's structural. The models optimize for code that works, not code that survives contact with real users, real money, and real attackers.

So both things are true. Your customer can build something that works, and the distance between "works on my laptop" and "I trust this with my clients' money" is as wide as it's ever been. The trouble is your customer doesn't know that yet, which is now your problem to solve.

Your new first objection

Every product used to compete against two things: the alternative product, and doing nothing.

You now compete against a third thing that's harder to beat than either of them. You compete against what your customer believes they could build themselves this weekend.

That objection shows up before pricing, before features, before anything. If you can't answer it in one sentence, the rest of your pitch doesn't get heard.

The wrong way to answer it is to argue. Telling a customer their prototype is garbage is a great way to lose a customer who's now emotionally invested in their prototype.

The right way is to be positioned somewhere the argument never comes up. That means knowing precisely what AI can already do for your customer, and building where structurally it can't reach.

Which brings me to how I found that line in my own market, through a lot of trial and error.

What accountants taught me about AI

One of the tools I'm building right now is fintech software for financial services firms. Early on I did what everybody does. I looked for how I could leverage AI to blow their minds. Then I ran into a wall that reshaped my entire product strategy.

Financial services firms cannot tolerate unpredictable results. Run the same numbers through the same process twice, get two different answers, and you don't have a helpful tool, you have a liability. Their work gets reviewed. It gets defended. Somebody signs their name to it.

Here's the technical reality a lot of founders aren't fully acknowledging about AI. Language models are non-deterministic by design, and you largely don't have the ability to change that behavior. It's built into the foundation of an LLM.

Thinking Machines Lab measured this precisely. They ran the same prompt one thousand times on a large open model. They got 80 different responses.

Here's my favorite detail. All thousand responses were identical for the first 102 tokens. Every single one wrote that the subject was born on May 11th, 1918. Then 992 of them said "Queens, New York" and 8 of them said "New York City."

The cause isn't randomness in the model. Inference servers batch requests together, and the batch size changes based on how many other people happen to be using the system at that moment. Different batch size, different order of floating point math, different result. Your answer depends on the server's traffic.

You can adjust this behavior with specialized work, but it isn't fixed by default in the tools your customer is using, and that's what really matters.

Now put that in front of a professional whose regulator requires a documented, reviewable trail. Audit standards require that a reviewer can understand what a tool did and how its output was evaluated. "It gave me a different answer today than yesterday and I'm not sure why" fails that test instantly.

That single discovery told me more about my roadmap than a hundred feature requests ever would. It told me exactly which parts of the workflow AI can own, which parts it must never own, and where my product earns the right to exist.

That's not just an insight. That's a template.

Find your version of the same gap

Every market has a gap. The question is which one is yours. Here are the five places these gaps consistently live.

Reproducibility. Anywhere the same input has to produce the same output, every time, forever. Finance, accounting, payroll, legal, compliance calculations, pricing, just about anything in the business world these days.

Accountability. Anywhere a human has to sign their name and carry the consequence. AI can draft the thing, it cannot own the outcome, and somebody has to at almost every company.

The audit trail. Not just what the answer was, but what the inputs were, which version of the logic ran, who approved it, and when. That's a systems problem, not a model problem.

The system of record. AI is genuinely great at producing an answer, and mediocre at being the place the answer lives, gets updated, gets permissioned, and gets pulled from years later.

Cost of being wrong. This is the one that sorts every market. Ask what happens when the output is wrong. Wrong tweet, who cares. Wrong tax filing, wrong dosage, wrong wire transfer, wrong lien deadline, and suddenly nobody is vibe coding their own solution.

Run your market through those five right now. Whichever one lands hardest is where your moat goes. If none of them land hard, that's worth knowing too, since it means your market probably will get eaten. You should either move up into a market where the stakes are higher or plan for a different kind of business.

The design pattern: deterministic spine, AI at the edges

Here's the actual pattern, and this is the part I want you to implement.

Stop thinking about "adding AI to your product." Think in three layers instead.

The edges are where AI belongs. Intake, extraction, classification, drafting, summarizing, explaining, answering questions in plain English. Messy input, tolerant of variance, a human is going to look at it anyway. AI is genuinely excellent here and you should use it aggressively.

The spine is where AI never goes. Your calculations, your rules, your state transitions, your money movement. Plain, boring, deterministic code. Versioned. Tested. Same input, same output, forever.

The log is what makes the whole thing defensible. Every input, which version of the rules ran, what the AI suggested, what a human approved, timestamped and immutable.

The rule that ties it together, and this is the sentence I'd put on a sticky note:

> AI proposes, the spine decides, the log proves it.

Look at what that gets you. Your customer gets all the speed of AI on the miserable parts of their job, the data entry, the reading, the drafting. They get none of the risk on the parts where being wrong is expensive. When their reviewer asks how a number was produced, there's an answer.

Try building that in a weekend. That's not a prompt, that's a system, and systems are what people actually pay for.

Beat them here, join them there

Now the part founders get wrong in the other direction. Some people hear all this and conclude they should keep AI out of their product entirely. That's just as bad a mistake.

The spine is where you beat AI. It's yours, it's stable, it's the thing that can't be prompted into existence.

The edges are where you join it, in two different ways.

The first is putting AI inside your product on those messy input tasks, which makes your software faster and less annoying to use.

The second is the one most founders are sleeping on. Your customers are building their own AI workflows right now, and those workflows need access to your data. If your product is easy to reach from the tools they're already using, you stop being one more app they log into and start being infrastructure in their stack. If instead you're hard to reach, their AI will route around you.

So the goal isn't to be AI-proof. The goal is to be the reliable piece that everybody's AI plugs into. That's a much better and stickier business than either extreme.

Why this is a moat, not a feature

Let me address the obvious objection. Won't the next model just close all of this?

Look back at the two studies. Security pass rates stayed flat for three years while capability climbed. The nondeterminism problem needed specialized engineering on the inference stack, not a bigger model. These aren't gaps that shrink automatically as the models improve.

More importantly, most of what I described isn't a model problem at all. An audit trail is a systems design decision. Accountability is a legal and organizational structure. Being the system of record is earned over years of your customer's data living in your product.

Notice what that means. The pattern gets stronger as AI gets better, since the more capable AI becomes at the edges, the more valuable a trustworthy spine becomes. Somebody has to be the part of the stack you can bet the business on.

That's the position you want.

Your playbook to follow

  1. Write down what your customer can already do with the AI tools they have today. Be honest and be specific. Better yet, go build the weekend version yourself and see how far it gets.
  2. Run your market through the five gaps. Reproducibility, accountability, audit trail, system of record, and cost of being wrong. Find the one that lands hardest.
  3. Draw your three layers. Name exactly what lives at the edges, what lives in the spine, and what goes in the log. Anything in the spine that currently depends on a model needs to come out.
  4. Make your product easy for their AI to reach. Clean API, clear docs, an MCP server if it fits. Be infrastructure, not a destination.
  5. Put the answer in your marketing. One sentence, on your homepage, for why building it themselves won't work. Make them see the gap before they waste a weekend finding it.

Where to go next

If steps one and two are where you're stuck, that's exactly what my free SaaS Idea Validator does. It walks your idea through whether it actually holds up, including against what your customer could put together themselves: tools.bootstrappersparadise.com/validator

If you want to work through your own positioning against AI with me directly, I work with a small number of founders for private 1:1 coaching: bootstrappersparadise.com/#coaching

The lower barrier didn't take the opportunity away. It moved the opportunity to the parts of the problem that were never just about writing code in the first place. Go find yours.

Ready to Build Your Own SaaS?

Learn how to go from idea to launch in my free 5-day email course — no coding or big budget required.

Start the Free Course