Skip to main content

P3. AI app path

What this page helps you do​

Follow a safer launch path for an app where AI is part of the product, not just a hidden helper.

Why it matters​

AI apps add extra failure modes. The app can be online and still feel broken because results are too slow, too expensive, too unreliable, or too unsafe.

You should already have​

  • an app that uses models, prompts, retrieval, agents, or generated output in a user-facing way

Skip this page if​

  • AI is not part of the core user experience

Then go to P2. SaaS web app path.

What to do​

Follow the normal web app path plus AI-specific checks:

  1. Start with P2. SaaS web app path.
  2. Make sure model keys live in F3. Environment settings, not in code.
  3. Add usage controls and abuse protection with C4. Reduce spam and abuse.
  4. Decide what happens when the model is slow, fails, or costs too much.
  5. Add logs and error tracking with R6. Error tracking and R7. Logs.
  6. Review the AI-specific checklist in agent/checklists/ai-app-launch.yaml.

Questions worth answering before launch:

  • What happens if the model provider is down?
  • What happens if a user sends a huge prompt or file?
  • What happens if the output is wrong, unsafe, or empty?
  • What happens if costs spike?

Start with one reliable model path, a hard usage limit, and clear logging before you add fancy fallback behavior.

Common mistakes​

  • logging too little to debug model failures
  • logging too much sensitive user data
  • launching with no cost guardrails
  • assuming prompt quality is the only thing that matters

Next step​

Go to F3. Environment settings or C4. Reduce spam and abuse.

Advanced notes​

AI apps often need queueing and job processing earlier than builders expect. If heavy work happens outside the request-response cycle, see B9. Need background jobs.