Defining Failure Contracts for AI Features in SaaS ProductsDefining Failure Contracts for AI Features in SaaS Products
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Before adding AI to your SaaS, write the failure contract.Most AI feature briefs describe what should happen when the model works.Production problems begin when it doesn’t.Before adding AI to an existing SaaS product, I think the team should define: 1. LatencyHow long can the user wait before the product falls back, continues asynchronously, or offers another path?2. UncertaintyWhat happens when the output is incomplete or confidence is too low? Does the product ask for clarification, request human review, or refuse the action?3. PermissionsWhich records can the model access for this user, role, and organization? AI should inherit the product’s access rules rather than bypass them.4. Action boundariesCan the AI recommend, draft, or execute? Sending an email, changing a payment state, and updating a customer record should not share the same approval rules.5. CostWhat is the usage limit per user or tenant? Which model or workflow becomes the fallback when a request is too expensive?6. RecoveryCan the team see which model, prompt, data, and tool call produced the result? Can a failed workflow be retried without duplicating the action?Connecting an API is usually the easy part. The real product work is deciding how the feature behaves when reality does not match the demo.If you are building AI into a product, which part is hardest to define: latency, permissions, human approval, cost, or recovery?
Eric's avatar
Recovery is the one I find hardest to define. If an email goes out and the next step fails, I want the retry to know it was sent so the customer does not get it twice.
Waleed's avatar
Exactly. The important distinction is between retrying the workflow and replaying its side effects. I’d persist an idempotency key and an outbox or event record before advancing to the next step, so a retry can reuse the existing email result instead of sending it again. The...
Eric's avatar
I’d resume automatically if the next step is safe to repeat and the user can see what already happened. If an email or record update is still uncertain, I’d pause and ask someone to review it before continuing.
Waleed's avatar
That is a useful boundary: automate only when the system can prove the next step is safe and the user can see the prior outcome. I would make that proof explicit in the workflow state—completed side effects, idempotency key, and a reason for the chosen recovery path. “Uncertain”...
Sunil's avatar
Recovery, for me. Latency and cost you can put a number on, but deciding what is safe to retry for each action is a real product decision. Idempotency keys on every AI-triggered action are the first thing I'd add, so a retry never sends the same email or updates the same record twice.
Waleed's avatar
Agreed—the safe retry policy belongs in the product definition, not only in infrastructure. I would pair the idempotency key with a durable action record that stores the intended effect, execution status, and provider response. Then the workflow can distinguish “never...
Sunil's avatar
The "outcome unknown" state is the piece most systems skip, and it's exactly where the double-charges and duplicate emails come from. Treating it as a human-review queue instead of an automatic retry is a great pattern. Saving this thread, thanks Waleed.
Back to feed
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started