The pattern that works

Start where AI assists rather than decides — drafting, summarising, suggesting. Users stay in control, errors are visible and correctable, and you learn how your customers actually use it before betting anything on autonomy.

Adding AI to a working product is a different problem from building an AI product. The constraint is not capability — it is not destabilising something customers already depend on.

Where to start

Feature typeRiskValueGood first move?
Summarise existing contentLowModerateYes
Draft text the user editsLowHighYes
Search over user's own dataLowHighYes
Suggest next actionsLowModerateYes
Auto-categorise recordsModerateHighWith review
Take actions automaticallyHighHighLater
Make decisions for the userVery highVariesRarely

"Draft, don't send" is the highest-value low-risk pattern. The AI composes; the user reviews and sends. You capture most of the time saving, errors are caught before they matter, and users feel in control — which is what determines whether they keep using it.

The infrastructure decisions that are hard to reverse

  1. Abstract model calls behind your own interface from the first feature. Provider switching becomes configuration rather than refactoring.
  2. Cost attribution per customer. Without it you cannot tell which accounts are expensive, or price the feature rationally.
  3. Decide the data policy before building. What customer data leaves your environment, under which vendor terms, and what you tell customers.
  4. Build the evaluation set early. It is what lets you change models or prompts safely later.
  5. Instrument quality signals — acceptance rate, edit rate, regeneration rate.

The data policy decision is the one that causes retrofits. If your terms of service and DPAs do not cover sending customer content to a third-party model provider, you may need to update them, notify customers, or offer an opt-out. Finding this out after launch is considerably worse than before.

Pricing and cost exposure

Unlike most features, AI has a marginal cost per use. That changes the economics:

  • Model the cost per active user at realistic usage before launch.
  • Identify your heaviest plausible user — a small number of power users can dominate spend.
  • Set per-plan limits, communicated clearly rather than enforced silently.
  • Route simple requests to cheaper models — most calls are not the hard ones.
  • Cache aggressively where content is stable.

A feature that delights users and loses money on your heaviest accounts is not a success. Model the worst-case user, not the average one.

Designing for trust

Adoption depends on whether users believe the output:

  • Show sources for anything factual, linked to the underlying record.
  • Make output editable rather than final.
  • Indicate uncertainty honestly rather than presenting everything with equal confidence.
  • Allow regeneration with feedback, so a poor result is not a dead end.
  • Never hide that it is AI-generated. Users find out, and discovering it feels like deception.
  • Provide an off switch for customers who prefer not to use it.

Rollout that protects the existing product

  1. Internal use first — your own team on your own data.
  2. Opt-in beta with a small group of engaged customers who will give feedback.
  3. Measure acceptance and edit rates — a high edit rate means the output is not good enough yet.
  4. Widen gradually, watching cost per customer alongside usage.
  5. Default on only when quality and economics are both proven.

Signals worth watching

SignalWhat it tells you
Acceptance rateWhether output is usable as-is
Edit rate and sizeHow far off it is
Regeneration rateFirst attempt failing
Feature abandonmentTried once, not returned to
Cost per active userWhether the economics hold
Support tickets mentioning itConfusion or distrust

What not to do

  • Do not add AI because competitors did. A feature nobody asked for still costs money to run.
  • Do not make it unavoidable. Users who do not want it should be able to work as before.
  • Do not let it write to customer data unreviewed in the first version.
  • Do not launch without cost attribution. You will not be able to price it or diagnose a bill.

Adding AI to a product customers already rely on? Tell us the workflow you want to assist. See our AI agent service, cost control, and observability.

Frequently asked questions

Usually not at first. Bundling it into existing plans lets you learn what customers actually use before pricing it. Separating too early creates a small paying cohort and no signal about broader value. Once usage patterns are clear, tiering becomes an informed decision.
It happens, and it is why usage-based costs need modelling before launch. Options are per-plan caps, routing simple requests to cheaper models, caching aggressively, or pricing the feature separately. Discovering the problem from an invoice is the expensive path.
More readily when the output is verifiable. Features that show sources, allow editing before use, and clearly indicate uncertainty get adopted. Features that produce confident opaque answers get tried once and avoided.