Every client conversation now includes some version of “can we add AI to this?” Often the answer is yes, and a good one. But AI features fail differently from the software around them: they’re probabilistic where the rest of the system is deterministic, they can be confidently wrong, and their behavior shifts when a model provider updates something you don’t control. Adding them to a product used by millions means respecting those differences instead of pretending they aren’t there.
AI belongs at the edges, not the foundation
The first rule we apply is about placement. AI is excellent at the edges of a product — drafting text, summarizing, suggesting, ranking, answering questions — where a human stays in the loop and a wrong answer is an inconvenience, not a catastrophe. It does not belong in the load-bearing core, where a hallucination becomes a wrong invoice, a lost record, or a corrupted database.
So we draw a hard line. The parts of the system that simply must be correct stay deterministic, tested, and boring. AI sits on top of that foundation, never inside it.
Design for being wrong
Traditional code is wrong because of a bug you can find and fix. An AI feature is sometimes wrong by nature, and no amount of debugging removes that. The honest response is to design for it from the start:
- Show your work. Surface sources, confidence, or the underlying data so users can sanity-check a suggestion instead of trusting it blindly.
- Make the human the decision-maker. The model proposes; the person disposes. The easier it is to edit or reject an AI output, the safer the feature.
- Fail to a known state. When the model is unavailable, slow, or unsure, the product should degrade to something predictable — not throw an error or, worse, guess.
A feature built this way stays useful even on the days the model has a bad answer.
The provider is a dependency like any other
Most AI features lean on a model you don’t host and can’t freeze. That’s a normal dependency — and we treat it like one. We keep the provider behind a thin internal interface so swapping or adding models is a small change, not a rewrite. We watch latency, error rates, and cost the same way we watch a database. And we set budgets, because an AI feature with no spending ceiling is an incident waiting to happen.
This is the same discipline behind our 99.8% uptime: the parts of the system you don’t control get wrapped in the parts you do.
Measure whether it actually helps
The last step is the one most teams skip. An AI feature that demos well can still make a product worse — more confusing, slower, more expensive per user. So before a feature graduates from “shipped” to “permanent,” we look at whether people use it, whether it saves them time, and what it costs to run. Features that don’t earn their place get removed, exactly like any other code.
AI is genuinely changing what we can build, and we ship it every week. But the products that keep millions of people coming back aren’t the ones with the most AI — they’re the ones where it’s used with judgment.
If you’re weighing where AI fits in your product, let’s talk through it — including the places we’d tell you to leave it out.