Building with an AI assistant without losing control

For a small product, an AI assistant can now write most of the code: pages, forms, database queries, email templates, admin screens. That's a real change, and it's why more people than ever can launch software alone. It also means more products reach real customers with code nobody fully read.

This guide is about the parts you can't delegate: the four areas where mistakes cost money, data or trust, how to review AI-written code without reading every line, and what to check before real users arrive.

What to delegate, what to own

The left column fails visibly: a button looks wrong, a form misbehaves, you notice. The right column fails silently: everything looks fine until a customer sees someone else's data, or a bill arrives.

Secrets never go in code

API keys, database passwords and payment secrets belong in environment variables set in your hosting dashboard, never in your code or repository. Assistants sometimes paste a key directly into a file to "make it work", especially when you paste an error message that includes one.

• Keep a .gitignore entry for local environment files from the first commit.
• Search the project for anything that looks like a key before every commit.
• Don't paste real keys into a chat with an assistant; use placeholders.
• Separate test keys from live keys, and only put live keys in production settings.

Who can see what

The most serious mistakes in small products are about data access: one customer able to see another customer's records. Many hosted databases rely on row-level rules that decide which rows each signed-in user may read or change. Assistants can write these rules, but they also sometimes switch them off "temporarily" to fix an error.

Repeat this test after any change that touches data access, and especially after an assistant "fixes" a permissions error.

Payments and webhooks

Your product learns that someone paid through a webhook: a message from the payment provider to your server. AI-generated webhook handlers often work in the happy path and fail in the others. Check that the code:

• Verifies the webhook signature, so nobody can send a fake "payment succeeded" message.
• Handles the same event arriving twice without granting two months of access.
• Handles failed payments, cancellations and refunds, not just successes.
• Never trusts prices or plan names sent from the browser; it reads them from the payment provider.

Then test with a real card: pay, refund, let a payment fail, cancel. Disputes cost $15 each on a common processor^[5], so getting cancellations right is cheaper than it looks.

How to review AI-written code

You don't need to read every line. You need to read the right lines.

• Ask for small changes. "Add a delete button to the receipts list" is reviewable. "Build the dashboard" is not.
• Read the diff, not the whole file. Look first for anything touching sign-in, database rules, payments, environment variables or external calls.
• Run it after every change. Click through the path a customer takes.
• Ask the assistant to explain anything in the risky areas, then check the explanation against the provider's documentation.
• Be wary of new packages. Check that every library the assistant adds exists, is maintained and is widely used. Invented or abandoned package names are a known risk.
• Commit often, so you can go back to the last working version in one step.

Keep bills under control

Generated code can make far more requests than needed: an API call on every keystroke, a page that refetches data every second, a background job that never stops. On usage-billed services, that becomes money.

• Set a spending limit wherever one exists. Some paid hosting plans include spend management^[3]; some free plans have hard limits that pause instead of billing^[4].
• Turn on usage alerts at 50% and 80% of what you expect to use.
• Check usage dashboards weekly for the first month. A sudden spike is more often a bug than a rush of new users.
• If your product calls an AI model, set a per-user limit on calls from day one.

Backups you've actually tried

Know where your data is backed up, and restore it once before launch. On Supabase, Pro projects get daily backups with the last seven days kept; the documentation doesn't list automatic backups for free projects and recommends exporting data regularly yourself^[2]. Pro starts at $25 a month^[1]. Until you've restored a backup once, you don't know it works.

Before real users arrive

Where AI-built products usually slip

• Accepting a "fix" that disables a security rule to make an error go away.
• Letting the assistant pick the architecture without understanding where data lives.
• Huge changes in one go, which nobody can review.
• Testing only as yourself, the admin, never as a normal user.

Questions

Run the two-account test today; it takes ten minutes. Then work through the before-launch table, and follow the launch week plan for everything that isn't code.