Building a SaaS with AI is two builds, not one

Two builds, not one

In a randomized trial published by METR in July 2025, 16 experienced open-source developers took 19% longer to finish 246 real tasks when allowed to use early-2025 AI coding tools — and reported afterward that they thought they had gone about 20% faster (METR). Keep that number in view.

Building a SaaS with AI is two builds, not one. The first is using AI to write the product: a tooling decision, settled in an afternoon, reversible for $20. The second is shipping AI inside the product — an architecture and cost-of-goods decision that sets your margin and your uptime.

The second one is the hard half.

What the code-generation half actually buys

Adoption is not in question. The Stack Overflow Developer Survey 2025 found 84% of respondents using or planning to use AI tools, with trust moving the other way — 46% said they distrust the accuracy of the output, and the most-cited frustration was code that is "almost right, but not quite" (Stack Overflow).

That gap between adoption and trust is the whole story of the first build. AI generates plausible code quickly. Plausible code that is almost right is the most expensive kind, because reviewing it costs more than writing it would have.

Where it reliably pays:

• Greenfield scaffolding. Auth, CRUD, a Stripe checkout, migrations, a settings page. Patterns with a million public examples.
• Test generation against code that already exists and already works.
• Throwaway internal tools. Admin scripts, data backfills, the dashboard only you will see.
• Reading unfamiliar code. "Explain what this module does" is where the models are strongest and the downside is zero.

Where I would not use it unsupervised: anything touching money movement, permissions, or tenant boundaries. Not because the model can't write it — because the failure is silent and the blast radius is every customer.

Tooling is a $20/month decision, not a strategy. Cursor Pro is $20/month (Cursor pricing); Claude Code ships with Anthropic's paid plans and via the API (Anthropic). Pick one, stop reading comparison posts, go build.

I would not let an agent merge to main without a human reading the diff. That is not caution for its own sake. It is the 19% finding, which says the perceived speedup and the real one diverge, and the only instrument you have for catching the divergence is review.

The product half: contain nondeterminism to one node

An LLM feature is a distributed system with one nondeterministic node in the middle. Everything you build around it exists to keep that node from contaminating the rest.

Four parts, and every one of them is ordinary software:

Input filter. Untrusted text from a user, an email, a scraped page, or a PDF never goes straight into the context window as instructions. Prompt injection is LLM01 — the top entry in the OWASP Top 10 for LLM Applications (OWASP). Treat retrieved content as data, label it as data, and keep tool permissions out of its reach.

Model call. One call, one job, typed output. Structured Outputs constrains the response to a JSON schema you supply, which removes an entire category of parse-failure code (OpenAI).

Step cap. Enforced outside the model, always. The OpenAI Agents SDK takes a max_turns argument and raises MaxTurnsExceeded when the loop exceeds it (Agents SDK docs); LangGraph ships a graph recursion limit that errors rather than spinning (LangGraph). Unbounded loops are the most common production failure in agentic systems, and no prompt instruction fixes them. A prompt is a request. A cap is a guarantee. I wrote more about why caps come before capability in starting a company with AI, one capped agent at a time.

Commit. The write to your database, the email that sends, the refund that issues. This is the only irreversible step, and it should be the only place a human approval gate can be inserted without rewriting anything.

If you connect tools through Model Context Protocol (MCP), the allowlist question gets sharper, not softer: an MCP server is a set of capabilities you are handing to a nondeterministic caller. Enumerate them. Scope the credentials per tenant.

Your COGS now has a token line

Pre-2023 SaaS had near-zero marginal cost per request. That is over for anything with a model in the path. Input and output tokens are priced per million on both major vendors' public pricing pages (OpenAI, Anthropic), and output tokens cost several times what input tokens cost on every frontier model.

Run the arithmetic before you pick a price. Take a support-triage feature: each job runs about 8 model turns, carries roughly 12,000 input tokens of context per turn, emits ~800 output tokens, and fires 5,000 times a month across your customer base.

Change the model picker and watch the monthly number move by an order of magnitude. That is your gross margin, and it is a product decision, not a finance one.

Three levers that are documented and real:

Fixed infrastructure barely registers next to this. Managed Postgres on Supabase Pro is $25/month (Supabase). Your token bill will pass that in a week. Decide early what you host and what you rent — I laid out that boundary in self-hosted AI agents: what to run yourself, what to rent.

The three failures that actually take products down

Not hallucination. Hallucination is a quality problem you manage with evals. These three are outages.

Unbounded loops. An agent decides the task is not done, calls a tool, re-reads the result, decides again. Without a cap enforced in code, the ceiling is your API spend limit. The fix is the cap, plus a hard timeout, plus an idempotency key on every tool that writes.

Prompt injection reaching a tool. The dangerous shape is not "the model said something rude." It is a model with database write access reading a support ticket that contains instructions, and following them. OWASP ranks this first among LLM application risks (OWASP) because the mitigation is architectural: least-privilege tools, per-tenant credentials, and no path from untrusted text to a privileged action without a deterministic check in between.

Cross-tenant leakage through the context window. Retrieval pulls a chunk, the chunk belongs to another customer, the model summarizes it faithfully. Application-layer filtering is not enough when the retrieval query is itself model-generated. Enforce isolation in the database with row-level security policies (PostgreSQL) so a wrong query returns nothing instead of returning someone else's data.

All three have the same shape. The model is not the thing that broke. The thing that broke is the absence of a boundary around the model.

Evals are the release gate, not a nice-to-have

You cannot regression-test a nondeterministic system with assertions. You test it with a graded set of cases and a score you refuse to ship below.

The mechanics are not exotic — a set of inputs, an expected behaviour per input, and a grader that is either exact-match, a rule, or another model call (OpenAI evals guide). What matters is where the cases come from. The useful ones come out of production failures: every time the feature does something wrong for a real customer, that case goes in the set, permanently.

I would not ship a model-dependent feature without this, for one reason that has nothing to do with your code quality. Vendors deprecate and update models. A prompt tuned against one snapshot can degrade on the next, and without a scored set you will find out from a customer. Pin model versions explicitly in your API calls. Re-run the set before you move the pin.

For a worked example of the shape — inputs, typed output, grading — see build an AI agent that qualifies inbound leads from a CSV.

What I would not build

I would not fine-tune before I had an eval set and a prompt I had already pushed to its limit. Fine-tuning converts a prompt you can edit in a second into an artifact you retrain. The standard sequencing in the field puts prompting, retrieval, and context design first, and treats fine-tuning as the step taken only once a scored eval set shows the remaining gap is in the model itself rather than in the material it was given.

I would not build a multi-agent swarm for v1. Agents that spawn agents multiply the loop-and-cost surface before you have a single working single-agent path. One agent, capped, with three tools, is a product. Five agents negotiating is a demo.

I would not ship "chat with your data" as the product. It is a feature of the model, not of your company. The buyer is paying for an outcome — a ticket triaged, a lead scored, a report filed — and a chat box pushes the work of figuring out the prompt back onto them.

I would not give an agent spend authority yet. Not budget approvals, not ad buys, not refunds above a trivial threshold. The step cap protects you from the loop; nothing protects you from a confidently wrong decision executed at speed. Human in the loop on the commit step, specifically, is cheap and removable later. On the broader question of what these agents actually are, versus how they are sold, see what an AI SDR agent is, and what it is not.

Packaging, when your marginal cost is no longer zero

Per-seat pricing on a product with a token-denominated COGS is a bet that usage per seat stays flat. It does not. The power user who runs the feature 400 times a day pays the same $49 as the one who runs it twice, and your gross margin is set by whoever is heaviest.

Three shapes work. Seat plus included usage is the default: a seat price, a monthly allowance in units the customer understands — jobs, documents, reports — and overage above the line, with Stripe's meters handling both the metering and the invoice line (Stripe). Pure usage is right when consumption varies by 100x across accounts and wrong the moment your buyer needs a predictable number for a budget request. Outcome pricing — per qualified lead, per resolved ticket — aligns best and attributes worst, and it only works if your evals are good enough that you will put revenue behind the output.

Whichever you pick, instrument the token spend per account from the first paying customer, not from the first margin review. Per-account cost attribution is the baseline requirement for any business whose COGS is denominated in tokens: without a query that returns what a given account consumed last month, gross margin per customer is unknown, overage thresholds are guesses, and a single heavy account can erode the margin on an entire plan tier before anyone notices.

And the thing that none of this compresses: distribution. I took Metadata.io from $0 to $15M ARR and raised $50M doing it, and the model layer would not have changed the part that was hard. Getting a stranger to care, to trust you with their pipeline, to switch — that work did not get cheaper when inference did. The build got faster. The market did not get more patient.