Your AI app works locally. Now what?

You built something and it works. The obvious next step feels like deployment, but there's a set of things that need to be true first, and they have a strict priority order. Doing them out of order is how applications end up live and quietly leaking data.

First: stop leaking credentials

This is not a matter of taste and it comes before everything else. If an API key reaches the browser, it is public — bundled, inspectable, and extractable regardless of how it was stored.

• Search your client bundle for your key prefixes. Actually search it, don't assume.
• Every model provider call goes through your own server. Always. The client calls you; you call the provider.
• Anything prefixed to be publicly exposed by your framework is public — check what you put there.
• If a key was ever committed to git, rotate it. Removing the file does not remove the history.

Second: make authorisation server-side

The most common serious flaw in fast-built applications is authorisation that only exists in the interface. The button is hidden for free users, but the endpoint behind it doesn't check anything, and the endpoint is what an attacker calls.

Every endpoint that returns or modifies user data must independently verify who is asking and whether they're allowed. Not the component that renders the button — the handler that does the work. If your database supports row-level security, use it as a second line of defence, so a forgotten filter in application code cannot return someone else's rows.

Third: get a real data layer

Prototypes tend to accumulate schema by hand — a column added in a dashboard here, a table created in a console there. This works until you need a second environment, at which point nobody can reproduce the database.

• Migrations in version control, applied in order, so any environment can be rebuilt from scratch.
• Constraints and foreign keys in the database, not just intentions in application code.
• Backups, and at least one restore you have actually performed rather than assumed.
• Indexes on the columns you filter by — this is usually the difference between 40ms and four seconds.

Fourth: make failure visible

Deploy error tracking before you deploy features. The alternative is finding out about breakage from users, which means finding out about a fraction of it, late, without the context needed to fix it.

If a user has to tell you it's broken, you shipped without instruments.

The minimum is error tracking with source maps, a health check, and structured logs that include enough identifiers to trace one request through the system. Add uptime monitoring on the routes that matter most.

Fifth: handle the AI-specific failure modes

AI features have failure modes ordinary features don't, and they need to be handled before launch rather than after the first bad week.

• Timeouts on every model call, with a user-visible fallback state — never an indefinite spinner.
• Schema validation of model output, with a bounded retry when it doesn't parse.
• Rate limiting per user, so one script cannot spend your monthly budget in an afternoon.
• A cost ceiling with alerting, because usage spikes are not always legitimate.
• A logged record of what the model was asked and what it returned, for when someone disputes an answer.

Then deploy

Once credentials are server-side, authorisation is enforced at the endpoint, the schema is reproducible, failures are visible and the AI paths degrade gracefully — deploy. Not before. This list looks long, but it is a few days of work against the alternative of discovering each item individually in production, under pressure, with users watching.