Skip to content
NewSecurity Audit for AI-Built Apps. Fixed scope, clear report
GeekTech
Vibe Coding

Taking an AI-Built Prototype to Production

Your AI-built prototype works and users are arriving. What to add before it holds real data: tests, CI/CD, environments, monitoring, backups, cost limits.

5 min read

GeekTech Engineering Team18 years building and securing software

The prototype was built in a few weekends with Cursor, Lovable, Bolt or Replit. It works. People are signing up, and some of them are paying. Now the question changes from "does it work?" to "will it keep working, and what happens when it doesn't?"

That gap between a working prototype and a production system is mostly not about features. It's about the things AI coding tools rarely add unprompted: tests, safe deployments, separate environments, monitoring, backups and cost limits. This guide walks through them in a sensible order.

Signs you've outgrown the prototype stage

You don't need production discipline on day one. You need it when any of these become true:

  • Real customer data is stored, especially personal or payment data.
  • People depend on the app for their work, so downtime costs them something.
  • You deploy changes and sometimes break things you didn't touch.
  • More than one person, or more than one AI agent, is changing the code.
  • A customer, investor or partner has asked about security or reliability.

If two or more apply, the steps below are worth the time.

Step 1: Get the code under control

Start by making the codebase something you can reason about.

  • Version control with protected main. Every change goes through a branch and a pull request, even if you're the only reviewer. It gives you a history and a way back.
  • Read what was generated. Skim the whole codebase once. Look for duplicated logic, dead files, hard-coded values and secrets. AI-generated projects often contain two or three half-finished versions of the same feature.
  • Remove what you don't use. Unused routes, packages and database tables are attack surface and confusion with no benefit.
  • Write down the architecture. One page: what runs where, which services it depends on, where data lives. You'll need it for every step that follows.

Step 2: Add tests where breakage hurts

You don't need full coverage. You need tests on the paths that would hurt most if they broke:

  1. Sign-up, sign-in and password reset.
  2. Payments and anything that changes what a customer is charged.
  3. Access control: one user can't read or change another user's data.
  4. The core workflow your customers pay for.

AI tools are good at writing tests once you tell them exactly what to test. Describe the behavior and the failure cases, then review the tests as carefully as the code. A test that passes for the wrong reason is worse than no test.

Step 3: Make deployments boring

A good deployment process is one nobody thinks about:

  • CI on every pull request: install, lint, type-check, run tests and build. If any step fails, the change doesn't merge.
  • Automatic deploys from main, so production always matches the reviewed code.
  • Preview deployments for each pull request, so changes can be checked before they ship.
  • A tested rollback. Know how to return to the previous version in minutes, and try it once before you need it.
# Minimal CI: every pull request must pass these before merging
- run: pnpm install --frozen-lockfile
- run: pnpm lint
- run: pnpm typecheck
- run: pnpm test
- run: pnpm build

Step 4: Separate environments and secrets

Prototypes often have one database, one set of keys and one environment that serves as development, testing and production at the same time.

  • Create at least a development and a production environment, each with its own database and keys.
  • Never test against production data. Seed development with realistic fake data instead.
  • Keep secrets in your hosting provider's environment settings, not in the repository, and make sure none are exposed to the browser.
  • Use the provider's test keys for payments and email outside production.

This step also limits the damage of mistakes made by AI agents working in your codebase. An agent with access to a development database can't delete production records.

Step 5: Know when something breaks

If customers tell you about outages before your tools do, monitoring is missing. The minimum:

  • Error tracking that captures exceptions from both the server and the browser, with alerts for new error types.
  • Uptime checks on the home page, sign-in and your most important API route.
  • Structured logs you can search by user and request, kept long enough to investigate an issue reported days later.
  • A few business metrics such as sign-ups, payments and core actions per day. A sudden drop is often the first sign of a bug.

Route alerts to a place someone actually looks, and agree who responds out of hours, even if the answer is "nobody until morning."

Step 6: Backups you have actually restored

A backup you've never restored is a hope, not a backup.

  • Turn on automated daily backups, with point-in-time recovery if your database supports it.
  • Restore a backup into a separate environment once, and time how long it takes.
  • Store uploaded files with versioning or a separate backup.
  • Write a short recovery note: where backups are, who can restore them, and the steps.

Step 7: Control the bills

AI features and serverless platforms bill by usage, and usage can spike for reasons that have nothing to do with growth: a retry loop, a bot, an expensive model chosen by default.

  • Set spending alerts and hard limits with each provider.
  • Rate-limit public endpoints, especially anything that calls an LLM.
  • Cache repeated AI calls where answers don't change.
  • Use smaller models for simple tasks, and measure quality before and after switching.

A useful order of work

If time is short, do the steps in this order: secrets and access control, backups, monitoring, CI with tests on critical paths, environments, cost limits. The first three protect your customers; the rest protect your ability to keep shipping.

Keep using AI tools, with guardrails

None of this means giving up the speed that got you here. AI coding tools are still useful in production, as long as their work goes through the same pipeline as everyone else's: a branch, a pull request, CI, review and a preview deployment. The guardrails catch the mistakes, and you keep the speed.

The short version

A prototype becomes a production system when you can change it safely, see when it breaks, recover when it does and predict what it costs. Get the code under control, test what matters, automate deployments, separate environments, add monitoring and backups, and cap your spending. Then keep building.

Insights

Related insights

More on Vibe Coding →
  • Vibe Coding

    10 Security Mistakes in Apps Built with AI Tools

    The security gaps we see most often in apps built with Cursor, Lovable, Bolt and Replit, and how to check your own app for each one.

    6 min read

  • AI Security

    How to Secure AI Agents That Can Use Tools

    AI agents that call tools can take real actions. How to scope their permissions, contain prompt injection and test an agent before it touches production.

    6 min read

  • AI Security

    Prompt Injection Explained for Product Teams

    What prompt injection is, why it can't be solved with better prompts alone, and the design decisions that limit the damage in your AI features.

    7 min read

Get practical AI insights, monthly

AI security, automation and governance, written by engineers. No spam, unsubscribe any time.

Book a free 30-min call