Your AI SaaS, from zero to revenue

Conventional SaaS can charge per seat and ignore marginal cost, because serving one more user costs nothing meaningful. AI SaaS cannot. Generation costs real money per call, and usage across a customer base is heavily skewed — in every product we have instrumented, a small minority of users consume a large majority of inference.

Pure per-seat pricing on an unmetered AI product is therefore a bet that your heavy users stay rare. Sometimes that bet is fine; often it is how a growing product discovers negative margin on its best customers. The safer structures are hybrid — a seat price covering a generous included allowance, with transparent overage beyond it — or usage-based units tied to something the customer already thinks in: documents processed, matters researched, calls handled.

Whichever model you choose, meter from the first day even if you do not bill on it. You need cost per customer, per feature and per plan to price rationally, to notice an account whose usage has gone pathological, and to have a calm conversation with a customer using ten times what they pay for. Reconstructing that history later is not possible.

The architecture then defends the margin. Model routing sends the majority of calls to small fast models and reserves frontier models for the steps that genuinely need them. Prompt caching removes the cost of resending stable context. Quality tiers per plan are legitimate and common: a premium tier that routes to a stronger model is a product feature, not a compromise.

Target 70–85% gross margin on AI features. It is achievable, and the products that hit it designed for it before launch rather than discovering the problem at scale.

The failure that ends an AI SaaS is one tenant seeing another’s data. In AI products the surface is larger than in conventional SaaS because data flows through retrieval indexes, caches, model context and logs — each of which is a potential leak that a conventional access-control review would not examine.

We enforce isolation at the database layer with row-level security so a query missing a tenant filter returns nothing rather than everything. Application-layer filtering alone is one forgotten WHERE clause away from an incident, and that clause is forgotten eventually.

Retrieval indexes are partitioned per tenant. A shared vector store with tenant identity as metadata is a design we are frequently asked to remediate: a filtering bug or a malformed query does not degrade gracefully there, it returns another customer’s documents. Caches are keyed by tenant. Logs and traces redact content by default, because an engineer debugging a production issue should not be reading customer data incidentally.

For enterprise buyers who require it, we support dedicated infrastructure per tenant, and we design so that promoting a customer to isolated deployment is a configuration change rather than a rebuild. Deals that hinge on it appear sooner than most founders expect.

The pattern is consistent: a startup wins an enterprise pilot, and procurement then asks for SSO, SCIM, audit export, a DPA, a subprocessor list, data-residency options and a security questionnaire response. Each takes weeks to build under pressure, and the deal stalls for a quarter or dies.

The items are known in advance and cheap to build early. SSO via SAML and OIDC, SCIM provisioning so an enterprise can deprovision a leaver automatically, role-based access control with a permission model that survives contact with a real org chart, and exportable audit logs covering AI actions as well as user actions.

Then the documents: a data-processing agreement, an accurate subprocessor list that names your model providers, an architecture and data-flow diagram, an incident-response summary, and a written answer to the question every AI buyer now asks — is our data used to train models? The answer must be no, and it must be evidenced by your provider agreements, which means using enterprise endpoints with zero-retention terms from the beginning.

SOC 2 itself takes months and needs an auditor, but building SOC2-aligned from day one — access reviews, change management, logging, encryption, vendor management — means the eventual audit is a documentation exercise rather than a remediation project. We build to that standard by default because retrofitting it is several times the work.

A multi-tenant AI product processes untrusted input by design: customers upload documents, paste content, and connect data sources. Any of it can carry instructions aimed at your model, and in a multi-tenant context the consequence of a successful injection is not just a bad answer — it is potential access to tools and data across a session.

We treat all customer-supplied content as untrusted data rather than instruction. Embedded directives are neutralised before the content reaches the model, tool invocations are validated against the original user intent, and no retrieved content can escalate what the session is permitted to do. Output is filtered before it reaches a tool call or an external system.

Abuse control is the other half. Rate limits and per-tenant quotas prevent both accidental runaway usage and deliberate resource abuse. Content moderation on inputs and outputs is necessary if your product can generate open-ended text, both for your reputation and because your model provider’s acceptable-use policy makes you responsible for it. And anomaly detection on usage patterns catches the compromised account or the scraper before the invoice does.

The MVP most AI startups build is a prototype with customers attached: single-tenant assumptions, no metering, manual onboarding, and a model call hard-coded in a route handler. It gets to revenue quickly and then has to be substantially rewritten, usually at the worst moment.

Our MVP is deliberately narrow in features and correct in foundations. One workflow done properly, but with real tenancy, real billing, real metering, real auth and an evaluation harness. That takes eight to twelve weeks rather than four, and it removes the rebuild — every subsequent feature lands on a structure that already holds.

The design partner phase then earns the roadmap. Five to ten customers using the product for actual work, instrumented on acceptance rate, edit distance, regeneration and abandonment. What they do diverges from what they say more often than not, and the behavioural data is what tells you which of the next ten features is the one worth building.

General availability is then a commercial and compliance milestone rather than an engineering scramble: self-serve onboarding, the enterprise pack completed, support tooling in place, and cost per customer known well enough to price with confidence.