Checklist: from AI-built code to a live AWS app you own

An AI app builder gets you to a working preview fast. Getting from that preview to an app real people use, running in an AWS account you own, takes a few more steps. Most of them are small, and several are easy to miss because nothing breaks until someone finds them.

Work through this list in order. Each item says what to check and why it matters.

1. Get the code somewhere you control

• Sync the app to a GitHub repository in your own account. Lovable, Bolt, v0 and similar tools can push to GitHub. That repository, not the builder, becomes the source of truth for what goes live.
• Commit your lockfile (package-lock.json, pnpm-lock.yaml and so on). Without it, a deploy can install different package versions from the ones you tested.
• Add .env to .gitignore before the first commit, not after.
• Check the packages your AI tool added actually exist and are the ones you meant. A misspelled package name can install someone else's code.

2. Find every secret, and assume old ones leaked

• Search the repository and its history for keys: AWS, Stripe, OpenAI, Anthropic, a Supabase service role key, database passwords. A key that was ever pushed to GitHub, even for a few minutes, should be treated as public.
• Rotate any key you find, then remove it from the code. Deleting the line doesn't remove it from git history.
• Know which variables end up in the browser. Anything starting with VITE_, NEXT_PUBLIC_, REACT_APP_, NUXT_PUBLIC_, EXPO_PUBLIC_ or GATSBY_ is built into the files your users download, so anyone can read it. A Supabase anon key is fine there. A database connection string or a secret API key is not.
• Make a list of every setting your app needs, with which ones are secret. You'll need it when you deploy, and a missing value usually shows up later as an app that won't start.

3. Do a security pass on the code

AI tools tend to put checks where you can see them, in the UI, and leave the server open. Check:

• Every API route checks who is signed in, not just the page that calls it.
• Changing an ID in the URL doesn't show someone else's data. Sign in as one user, then try another user's record.
• Row Level Security is on for every table, if you use Supabase.
• Admin checks happen on the server, never only in the frontend.
• Database queries use parameters, not strings built from user input.
• CORS allows your own domains, not *.
• Storage buckets are private unless a file is meant to be public.
• Webhooks check their signatures (Stripe, GitHub and so on).
• Login, sign-up, password reset and AI endpoints are rate limited. An open AI endpoint is a way for anyone to spend your credits.
• Errors shown to users are generic. Stack traces and logs shouldn't include secrets or personal data.

4. Work out what kind of app it is

Where your app can run depends on what it is, and some AI-built apps change shape between prompts.

• A static site (a React or Vite single-page app, or a static Next.js export) is just files. It can be served from S3 behind CloudFront, with no server to run or patch. It also has nowhere to keep a secret, so any code that needs one has to move to an API.
• A server app (Next.js with server rendering, Express, FastAPI, Django) needs somewhere to run, such as a container on ECS Fargate, and usually a Dockerfile.
• SQLite won't survive on a container. The file is lost when the container is replaced. Use Postgres.

5. Decide where your data lives

• Keep your existing database (Supabase, Neon, Atlas) or create Postgres in your own AWS account. Either works. Decide before you deploy, and know the monthly cost of the second.
• Connect over TLS with a password, not an IP allowlist. Container addresses change when they're replaced.
• Make sure backups are on, and try restoring one before you need to.
• Write migrations that the running version can live with. Add a column before the new code reads it, not in the same step. Then the old version keeps working while the new one rolls out, and you can roll back.

6. Set up the AWS account properly

• Use an AWS account you own, in your name or your company's. Your app, its data and its bill stay with you.
• Turn on MFA for the root user and don't use root for day-to-day work.
• Set a monthly budget alert in AWS Budgets. Billing data can lag by about a day, so it warns you; it doesn't stop spending.
• Set spending limits at your AI providers too. AWS can't see what your app spends with OpenAI or Anthropic.
• Don't store long-lived AWS keys in GitHub. Let GitHub Actions sign in with OpenID Connect (OIDC) and a short-lived role instead.

7. Deploy from code, not from clicks

• Define the infrastructure as code (AWS CDK or CloudFormation) and keep it in your repository. Then you can read it, review changes to it, and rebuild it.
• Deploy with a workflow in your repository, such as GitHub Actions, so every release runs the same steps.
• Review the deploy files as a pull request before anything runs in your account.
• Store secrets in AWS Secrets Manager and have the app read them by name, so values never appear in the repository, templates or logs.
• Finish each deploy with a health check that loads the real app, not a placeholder page.

8. Go live on your own domain

• Serve over HTTPS from the start. On AWS, CloudFront and an ACM certificate do this, and the certificate is free.
• Point a subdomain you own (for example app.yourcompany.com) at the app, and leave time for DNS and certificate checks.
• Update anything that still names the old URL: site URL variables built into the frontend, CORS allowed origins, and OAuth callback URLs at your sign-in provider.

9. Plan for after launch

• Decide when changes go live. AI tools often commit once per prompt. If every commit deploys, half-finished work reaches your users. Keep the builder's preview for trying things out, and release on purpose.
• Keep your AI tool away from the deploy files, or tell it which files not to touch. Many builders accept project instructions for this.
• Set up alerts for server errors and unhealthy instances, and confirm the alert email subscription so the alerts actually reach you.
• Know how to roll back to the last healthy version before you need to, and what a rollback won't undo: database changes and settings stay as they are.
• Re-check for secrets on every push, not just the first.

Where ScaleBop fits

ScaleBop works from the GitHub repository your AI tool syncs to, so you keep building in the same tool. It covers much of sections 4, 6, 7, 8 and 9: it works out whether your app is a static site or a container, writes the AWS CDK and GitHub Actions workflow into your repository as a pull request, deploys into your AWS account through OIDC, keeps secrets in Secrets Manager, serves HTTPS through CloudFront, adds alerts and an account budget, and gives you one-click rollback. Its security scan flags common problems from sections 2 and 3, and, once you're live on a subscription, holds back a release that adds a leaked key.

Some items stay with you, because they depend on what your app does: how it checks who is signed in, Row Level Security, rate limits and spending caps at your AI providers.

To see where your app stands, run the free readiness check on a public repository. You don't need an account.