Shipping an AI Prototype to Production Without Rewriting It

You spent a weekend prompting Claude Code into building a side project. It works. You tweeted about it. Now there's a real user. Maybe 10. Maybe someone wants to pay. The prototype was never designed to be a product, and the thought of a ground-up rewrite is depressing.

Good news: you don't need a rewrite. You need a hardening pass. Here's the minimum I'd do before letting strangers depend on a vibe-coded prototype.

1. Move All Secrets Out of the Code

The first thing to check: no API keys, database URLs, or passwords in any committed file. Search for them. Use environment variables. If you already pushed secrets to a public repo, rotate them right now, before reading the rest of this post. GitHub's secret scanner catches some, but bots watch GitHub events in real time and drain keys within minutes.

2. Wrap Every API Route in Real Auth

The prototype probably has routes like /api/delete-post with zero server-side auth check. The frontend hides the delete button, which feels like security but isn't. Anyone who opens devtools can hit those routes directly.

Add a wrapper: withAuth(handler) that validates the session and passes the user id to the handler. Apply it to every route that does anything. Yes, every one. Public endpoints are fine but there should be fewer of them than you think.

3. Add Rate Limiting on the Expensive Routes

If you have a /chat or /generate endpoint that calls OpenAI/Anthropic, a single malicious user can drain your account in hours. Per-user rate limits (say, 20 requests per minute) and a per-day spend cap using simple token counting. A minute of code saves you from a $4,000 bill.

4. Turn On Error Tracking

Free Sentry or Highlight takes 5 minutes. Without it, your first signal that production is on fire is a support email, and the email will come hours after the fire started. Wire it up, set up a Slack/Discord/email alert on new errors, done.

5. Catch and Show Errors in the UI

The prototype probably has a bunch of catch (e) { console.error(e) } patterns. Users see nothing and think the app is broken. Add an error state: a toast, a banner, anything that tells them "something went wrong, try again, or email [your address]."

6. Validate Env Vars at Startup

Add a Zod schema for required env vars and call it at server boot. If STRIPE_SECRET_KEY is missing, the server should refuse to start, not start happily and crash on the first payment attempt.

7. Add One Happy-Path Test

Not 100 tests. One. Playwright, signing up a user, clicking the main button, asserting the main output. Run it on every deploy. The point is not coverage — it's catching the moment you break the core flow, which you will, because you're vibe-coding improvements.

8. Set a Terms and Privacy Page

Not legal advice, but practically: you need a privacy policy if you're collecting emails, and a terms of service if anyone is paying you. Static pages, 10 minutes with a generator plus manual review. Legal defensibility comes later when you have real revenue.

9. Read the Full Git Log

Go through every commit since the prototype started. Look for committed secrets, debug prints, hardcoded test data, TODO comments with passwords. You'll find at least one thing you forgot about.

10. Run the Checklist Once

Before the first real user, run through the Vibe Code Fix checklist. Aim for Grade A or higher. Don't chase Grade S on day one — you'll burn yourself out. Grade A means the critical and high-severity stuff is handled.

What You Don't Need to Do

You do not need: full test coverage, a staging environment, CI/CD, feature flags, a monitoring dashboard, a design system, refactored code "for maintainability", or a proper database migration pipeline. Those come later, when you have real traction. The goal right now is "don't embarrass yourself and don't lose the user's data." Everything else is premature.