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.
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.
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.
authenticated session
enforced in the retrieval layer
that tenant's data only
within a usage budget
labelled as AI-generated
straight into the eval set
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.
Unit economics and the sub-processor question are week-one decisions. Both are expensive to revisit.
30-minute technical call · no deck
What we built, what stage it is at, and a link to the live thing wherever there is one.
yourOS is an operating system with an AI at its heart. You talk to it like a person, out loud or typed. It makes your calls, plans your days and works on your projects with a crew of agents, on your own private server. Our own product, built from the first commit; the waitlist is open.
Website, backend and app assets for Sonora, a free AI sound-therapy app on iOS and Android published by Cognitive AI.
Brand, website, prototype, apps on five platforms, the AI backend and the algorithm-intelligence pipeline for Podswap, a social growth engine that runs without a human in the loop.
In closed beta: Roxy, a private AI assistant with permanent memory running on infrastructure the user owns. Brand, site, product, backend and conversational design.
Live at coherence.com: brand identity generated with AI agents we directed, the motion system and website for the group behind Sonora, AboutAI, WakeUp and MudShadows. Agent work remains in build.
Live at domainbooth.com for DomainBooth, a premium domain brokerage: a new animated mark, every page redesigned and rebuilt with designed mobile layouts, and a custom CMS for its sales record, featured names, press and enquiries.
Apps, platforms and campaigns for these teams, long before the AI work. Every one is written up on the work page — what we did, and where our part ended.
