{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibmp7ul6hdjbpncy5u5llbespdkbvwtwekh6r7esofpq62wtuh6ue",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3moiajh6enck2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreic4m2fs3ofvmihr6lqyykpnrb5vbey2e56mul2alazpss52seilgy"
    },
    "mimeType": "image/webp",
    "size": 50720
  },
  "path": "/alex_mev/hardening-a-replit-ai-mvp-for-production-5775",
  "publishedAt": "2026-06-17T11:20:17.000Z",
  "site": "https://dev.to",
  "tags": [
    "replit",
    "ai",
    "vibecoding",
    "https://mev.com/blog/how-to-get-a-vibe-coded-replit-app-production-ready",
    "https://mev.com/services/vibe-code-to-production"
  ],
  "textContent": "A vibe-coded Replit app can survive a demo.\n\nProduction asks different questions.\n\nWhat 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?\n\nBefore you share the link outside your team, harden the app around a few boring files and rules.\n\nBoring is good here.\n\n##  1. Start with `replit.md`\n\nReplit's agent needs persistent instructions. Without them, each prompt session can drift from earlier decisions.\n\nCreate a `replit.md` file and treat it like a small production contract.\n\n\n\n    # Production rules\n\n    ## Security\n    - Every API endpoint must check authentication.\n    - Every user-owned resource must check authorization.\n    - Never expose secrets in client-side code.\n    - Do not create public endpoints unless explicitly requested.\n\n    ## Database\n    - Use migrations for schema changes.\n    - Do not modify production data directly.\n    - Keep dev, staging, and production databases separate.\n\n    ## Input validation\n    - Validate request body fields.\n    - Set file size limits on uploads.\n    - Reject unsupported file types.\n\n    ## External services\n    - Add rate limits for paid APIs.\n    - Add spending caps where the provider supports them.\n    - Log failed webhook events.\n\n    ## Code changes\n    - Do not rewrite unrelated functions while fixing a bug.\n    - Change only the affected files unless asked.\n\n\nThis does not repair weak code already generated. It does reduce new damage.\n\n##  2. Find Replit assumptions before migration\n\nA Replit prototype often depends on things you forgot were Replit-specific: secrets, URLs, storage, process behavior, or a bundled database.\n\nStart with a basic search.\n\n\n\n    grep -R \"replit\" .\n    grep -R \"localhost\" .\n    grep -R \"process.env\" ./src\n    grep -R \"sqlite\" .\n    grep -R \"uploads\" .\n\n\nThen check your runtime setup.\n\n\n\n    const port = process.env.PORT || 3000;\n\n    app.listen(port, \"0.0.0.0\", () => {\n      console.log(`Server running on port ${port}`);\n    });\n\n\nIf the app only runs inside the Replit workspace, it is still a prototype.\n\n##  3. Move secrets into explicit env config\n\nDo not migrate until you can describe every required variable.\n\n\n\n    DATABASE_URL=\n    SESSION_SECRET=\n    STRIPE_SECRET_KEY=\n    STRIPE_WEBHOOK_SECRET=\n    OPENAI_API_KEY=\n    SENTRY_DSN=\n    APP_ENV=development\n\n\nCommit the example file.\n\n\n\n    touch .env.example\n    git add .env.example\n    git commit -m \"Document required environment variables\"\n\n\nNever commit the real `.env`.\n\n\n\n    .env\n    .env.local\n    .env.production\n\n\nOuch if this is missing. Fix it early.\n\n##  4. Test authorization at the API layer\n\nAI-built apps often make login look finished while leaving the API too trusting.\n\nThe UI is not the security boundary.\n\n\n\n    app.get(\"/api/invoices/:id\", async (req, res) => {\n      const session = await getSession(req);\n      const invoice = await getInvoice(req.params.id);\n\n      if (!session) {\n        return res.status(401).json({ error: \"Unauthorized\" });\n      }\n\n      if (invoice.userId !== session.user.id) {\n        return res.status(403).json({ error: \"Forbidden\" });\n      }\n\n      return res.json(invoice);\n    });\n\n\nThen test the bad path.\n\n\n\n    curl -H \"Authorization: Bearer USER_A_TOKEN\" \\\n      https://example.com/api/invoices/USER_B_INVOICE_ID\n\n\nExpected result:\n\n\n\n    403 Forbidden\n\n\nIf you get invoice data back, stop adding features.\n\n##  5. Add limits before real users arrive\n\nYour app needs limits around uploads, paid APIs, and LLM calls.\n\nExample upload guard:\n\n\n\n    const MAX_FILE_SIZE = 10 * 1024 * 1024; // 10 MB\n\n    if (file.size > MAX_FILE_SIZE) {\n      return res.status(413).json({\n        error: \"File exceeds 10 MB limit\",\n      });\n    }\n\n\nExample AI usage guard:\n\n\n\n    if (user.monthlyTokensUsed >= user.monthlyTokenLimit) {\n      return res.status(429).json({\n        error: \"Monthly AI usage limit reached\",\n      });\n    }\n\n\nExample route-level rate limit:\n\n\n\n    import rateLimit from \"express-rate-limit\";\n\n    export const apiLimiter = rateLimit({\n      windowMs: 60 * 1000,\n      limit: 60,\n    });\n\n\nAttach it before the expensive route.\n\n\n\n    app.post(\"/api/generate\", apiLimiter, generateHandler);\n\n\nSmall guardrails save large invoices.\n\n##  6. Split environments before public testing\n\nUse three separate environments, even if the app is small.\n\n\n\n    local      -> local database\n    staging    -> staging database\n    production -> production database\n\n\nA minimal CI workflow is enough to start.\n\n\n\n    name: ci\n\n    on:\n      pull_request:\n      push:\n        branches: [main]\n\n    jobs:\n      test:\n        runs-on: ubuntu-latest\n\n        steps:\n          - uses: actions/checkout@v4\n\n          - uses: actions/setup-node@v4\n            with:\n              node-version: 20\n\n          - run: npm ci\n          - run: npm run lint\n          - run: npm test\n\n\nAdd smoke tests for login, checkout, upload, and any AI flow that costs money.\n\n##  7. Know when to bring in help\n\nYou can keep hardening the app yourself while the risk is low.\n\nBring in engineering help when one bad prompt could expose user data, trigger live payments, corrupt production data, or break a workflow customers depend on.\n\nMEV 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.\n\nUseful fit:\n\n  * you have a working Replit prototype\n  * users, money, or sensitive data are involved\n  * the agent keeps breaking working features\n  * integrations are half-finished\n  * you need a rebuild-vs-refactor call before launch\n\n\n\n##  Quick checklist\n\nBefore sharing the production URL, confirm this:\n\n  * `replit.md` has production rules\n  * company owns the repo\n  * `.env.example` exists\n  * secrets are out of code\n  * auth is checked on every API endpoint\n  * user-owned records have authorization checks\n  * uploads have size and type limits\n  * paid APIs have rate limits\n  * LLM calls have usage caps\n  * staging and production use separate databases\n  * CI runs before deploy\n  * errors are logged somewhere you check\n\n\n\nA Replit MVP is a strong starting point.\n\nProduction needs stricter rules, fewer hidden assumptions, and a path back when something breaks.\n\nFull original guide: https://mev.com/blog/how-to-get-a-vibe-coded-replit-app-production-ready\n\nMEV production-hardening service: https://mev.com/services/vibe-code-to-production",
  "title": "Hardening a Replit AI MVP for Production"
}