A vibe-coded Replit app can survive a demo.

Production asks different questions.

What happens when two users hit the same endpoint? Can one user read another user's records? Are Stripe live keys separated from test keys? What stops an LLM call from looping until the bill hurts?

Before you share the link outside your team, harden the app around a few boring files and rules.

Boring is good here.

1. Start with replit.md

Replit's agent needs persistent instructions. Without them, each prompt session can drift from earlier decisions.

Create a replit.md file and treat it like a small production contract.

# Production rules

## Security
- Every API endpoint must check authentication.
- Every user-owned resource must check authorization.
- Never expose secrets in client-side code.
- Do not create public endpoints unless explicitly requested.

## Database
- Use migrations for schema changes.
- Do not modify production data directly.
- Keep dev, staging, and production databases separate.

## Input validation
- Validate request body fields.
- Set file size limits on uploads.
- Reject unsupported file types.

## External services
- Add rate limits for paid APIs.
- Add spending caps where the provider supports them.
- Log failed webhook events.

## Code changes
- Do not rewrite unrelated functions while fixing a bug.
- Change only the affected files unless asked.

This does not repair weak code already generated. It does reduce new damage.

2. Find Replit assumptions before migration

A Replit prototype often depends on things you forgot were Replit-specific: secrets, URLs, storage, process behavior, or a bundled database.

Start with a basic search.

grep -R "replit" .
grep -R "localhost" .
grep -R "process.env" ./src
grep -R "sqlite" .
grep -R "uploads" .

Then check your runtime setup.

const port = process.env.PORT || 3000;

app.listen(port, "0.0.0.0", () => {
  console.log(`Server running on port ${port}`);
});

If the app only runs inside the Replit workspace, it is still a prototype.

3. Move secrets into explicit env config

Do not migrate until you can describe every required variable.

DATABASE_URL=
SESSION_SECRET=
STRIPE_SECRET_KEY=
STRIPE_WEBHOOK_SECRET=
OPENAI_API_KEY=
SENTRY_DSN=
APP_ENV=development

Commit the example file.

touch .env.example
git add .env.example
git commit -m "Document required environment variables"

Never commit the real .env.

.env
.env.local
.env.production

Ouch if this is missing. Fix it early.

4. Test authorization at the API layer

AI-built apps often make login look finished while leaving the API too trusting.

The UI is not the security boundary.

app.get("/api/invoices/:id", async (req, res) => {
  const session = await getSession(req);
  const invoice = await getInvoice(req.params.id);

  if (!session) {
    return res.status(401).json({ error: "Unauthorized" });
  }

  if (invoice.userId !== session.user.id) {
    return res.status(403).json({ error: "Forbidden" });
  }

  return res.json(invoice);
});

Then test the bad path.

curl -H "Authorization: Bearer USER_A_TOKEN" \
  https://example.com/api/invoices/USER_B_INVOICE_ID

Expected result:

403 Forbidden

If you get invoice data back, stop adding features.

5. Add limits before real users arrive

Your app needs limits around uploads, paid APIs, and LLM calls.

Example upload guard:

const MAX_FILE_SIZE = 10 * 1024 * 1024; // 10 MB

if (file.size > MAX_FILE_SIZE) {
  return res.status(413).json({
    error: "File exceeds 10 MB limit",
  });
}

Example AI usage guard:

if (user.monthlyTokensUsed >= user.monthlyTokenLimit) {
  return res.status(429).json({
    error: "Monthly AI usage limit reached",
  });
}

Example route-level rate limit:

import rateLimit from "express-rate-limit";

export const apiLimiter = rateLimit({
  windowMs: 60 * 1000,
  limit: 60,
});

Attach it before the expensive route.

app.post("/api/generate", apiLimiter, generateHandler);

Small guardrails save large invoices.

6. Split environments before public testing

Use three separate environments, even if the app is small.

local      -> local database
staging    -> staging database
production -> production database

A minimal CI workflow is enough to start.

name: ci

on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: npm ci
      - run: npm run lint
      - run: npm test

Add smoke tests for login, checkout, upload, and any AI flow that costs money.

7. Know when to bring in help

You can keep hardening the app yourself while the risk is low.

Bring in engineering help when one bad prompt could expose user data, trigger live payments, corrupt production data, or break a workflow customers depend on.

MEV is one vendor option for that stage. Their Vibe-Code to Production work is built around auditing Replit, Lovable, and AI-built MVPs, then hardening auth, secrets, AI integrations, observability, infrastructure, and deployment without forcing an automatic rewrite.

Useful fit:

• you have a working Replit prototype
• users, money, or sensitive data are involved
• the agent keeps breaking working features
• integrations are half-finished
• you need a rebuild-vs-refactor call before launch

Quick checklist

Before sharing the production URL, confirm this:

• replit.md has production rules
• company owns the repo
• .env.example exists
• secrets are out of code
• auth is checked on every API endpoint
• user-owned records have authorization checks
• uploads have size and type limits
• paid APIs have rate limits
• LLM calls have usage caps
• staging and production use separate databases
• CI runs before deploy
• errors are logged somewhere you check

A Replit MVP is a strong starting point.

Production needs stricter rules, fewer hidden assumptions, and a path back when something breaks.

Full original guide: https://mev.com/blog/how-to-get-a-vibe-coded-replit-app-production-ready

MEV production-hardening service: https://mev.com/services/vibe-code-to-production