Instrument theme
SaaS

Shipping AI inside your product.

An internal tool that fails is an inconvenience. A feature inside software your customers depend on fails in front of them, on their data, at their expense — and that changes almost every design decision.

Last reviewed 4 September 2026 · Engineering guidance, not legal advice.
THE FOUR CONSTRAINTS THAT ARE DIFFERENT
01

Cost per seat, not per call

Your pricing is probably per user per month. An AI feature with unbounded per-call cost attached to a flat subscription is a margin problem that scales with success. This has to be designed for on day one — usage caps, tiering, small models for the common path.
02

Latency inside an interaction

A user waiting inside your product is a different experience from a batch job. Streaming, optimistic UI and a smaller model on the interactive path are usually worth more than a marginal quality gain from a slower one.
03

Multi-tenant isolation

One customer's data must never appear in another's output. That means tenant scoping enforced in the retrieval layer, not in the prompt, and tested adversarially — because this is the failure that ends a contract rather than generating a ticket.
04

Their data, your feature

Your customers' contracts constrain what you may do with their data. Sending it to a model provider may require a DPA update, a sub-processor notification, or explicit consent. Ship first and discover that later is a genuinely expensive order of operations.
THE SUB-PROCESSOR CONVERSATION

This is the one that catches SaaS companies most often, and it is worth stating plainly. If you process customer data through a third-party model provider, that provider is very likely a sub-processor under your customer agreements. Adding one typically requires notification, sometimes gives customers a right to object, and occasionally requires renegotiation with your largest accounts — the ones whose legal teams read the notices.

Two consequences follow. First, this is a legal workstream that runs in parallel with the build rather than after it, and it can be the critical path. Second, it is a strong practical argument for self-hosting the model: a model running on your own infrastructure is generally not a new sub-processor at all, which can remove the notification, the objection right and the renegotiation in one move. Your hosting provider may still be one, and your customer contracts may restrict new processing purposes independently — your DPA and contract terms decide, and this is not legal advice.

For a SaaS company with enterprise customers, that is frequently the deciding argument — not cost, not capability, but not having to send a sub-processor notice to two hundred accounts and see what comes back.

DESIGNING FOR BEING WRONG

The feature will be wrong sometimes. The design question is what that looks like to a user, and it is answered in the interface rather than in the model. Suggestions a user accepts or rejects fail gracefully; actions taken automatically do not. Drafts are safe; sends are not. Showing the source a summary came from turns a wrong answer into a correctable one.

Give users a way to report a bad output, and route those reports into the evaluation set. That loop is the difference between a feature that improves after launch and one that is frozen at its launch quality because nobody knows which cases it fails on.

And be honest in the interface about what is AI-generated. Users tend to be more forgiving of a labelled AI suggestion that is wrong than of an unlabelled product feature that is wrong, the labelling costs almost nothing, and under EU AI Act Article 50 it is a requirement rather than a courtesy in several cases from August 2026.

TENANT ISOLATION IS THE HARD PART
REQUEST PATH
  1. Tenant request
    authenticated session
  2. Scope
    enforced in the retrieval layer
  3. Retrieve
    that tenant's data only
  4. Generate
    within a usage budget
  5. Return
    labelled as AI-generated
  6. Report bad output
    straight into the eval set
Solid: the request path Dashed: the feedback loop that keeps quality moving
Scoping is enforced outside the model, where a prompt cannot reach it. One tenant's data appearing in another's output ends a contract.
QUESTIONS
QUESTIONS — 3

Buy for a commodity capability that is not part of your differentiation. Build where the feature is the thing customers choose you for, or where your data is the moat. The failure mode we see most often is buying a platform for something that turned out to be core, then being unable to change it.

Carefully, and with an early view of unit economics. Flat inclusion is simplest and exposes you to heavy users; usage-based aligns cost and revenue but is harder to sell. Most land on inclusion with a fair-use cap, which needs the cap chosen from real usage data rather than guessed.

Yes, and for enterprise-facing SaaS it is frequently the deciding factor. A model on your own infrastructure generally adds no new sub-processor, which can remove the notification and objection process — though the infrastructure provider may itself be one, and your DPA and customer contracts decide. It is worth pricing that against the operational cost before assuming an API is simpler. This is not legal advice.

Keep reading
30-minute technical call · no deck

Ship it without
the margin surprise.

Unit economics and the sub-processor question are week-one decisions. Both are expensive to revisit.

CASE STUDIES

Shipped work.
Go and check it.

The work we can name, with the live site, our scope and the boundary made explicit. Select a project to see the evidence; each is a full case study, not a logo or a claim.

sonora.com
The Sonora homepage on desktop: a full-bleed dune landscape behind the headline “Transform Your Life with Sound”, with App Store and Google Play download buttons.
sonora.com — homepage, 1440×900 sonora.com →
Live Consumer wellness · Mobile + web

Sonora

Cognitive AI Ltd · 2026

A free sound-wellness app, described by its publisher as AI sound therapy that reads a short vocal sample at the start of a session and generates a soundscape for that moment. We designed and built the website and its backend, produced assets for the iOS and Android apps, and supported the application prototype.

Read the case study →

See every published project →

WHO WE HAVE BUILT FOR

Twenty-one years of applications, platforms and campaigns for names you know.

See all of our work →