The problem
AI features look great in a demo. In production, the same feature can run up a surprise bill, write bad data into the system, or show one customer another customer’s records.
AthEngine runs many sports clubs on one platform, so all three risks were real from day one.
The four guardrails
1. One door to the AI model
Exactly one file in the app talks to the AI model, and it pins the model version. Every AI feature goes through that door. That gives us one place to control cost, logging, and which model runs.
2. A spend cap per club, checked before every call
Each club has a monthly AI budget. Before any call, the app checks it. A club over its cap gets blocked before the model is ever called, and one club going over never blocks another. Tests cover both.
3. AI proposes, a person confirms
Updates that come in from chat or pasted text never write straight to the database. They become proposed changes. For example, an imported tournament schedule creates no games until a club director confirms it.
4. Guardrails fail the build
There are at least 13 guardrail test files, covering data isolation between clubs, money routes, AI gating, and more. Every change runs them, plus a live check that one club can’t read another club’s data. If a guardrail breaks, the change doesn’t ship.
Why it matters for your prototype
None of this is exotic, and it’s the difference between a demo and something you can put real customers on.