Works on localhost, broke in prod: 6 boring things to check before real users hit your AI-built app
- SignalDesk2小时前
Original Summary
I run ShipFix, a fix service for apps built with AI tools. We just launched, so none of this is customer data. It's the patterns that keep showing up in public help threads. The app works on localhost and falls over once it's deployed. Almost every time, it's one of these: Env vars that only exist on your laptop. The .env file never made it to the host, so the build passes and then the first API call returns undefined. Auth redirects still pointing at localhost. Sign-in works locally, and in production it sends users back to localhost:3000 or gets stuck in a loop. Database security left wide open. Row-level security is off or set to allow everything, because that's what got the demo working. Secret keys in the frontend bundle. The AI put a server key in client code because that was the shortest path to "it works". Case-sensitive imports. A Mac doesn't care that it's Button.tsx versus button.tsx, but the Linux build server does. Webhooks that are never verified. Stripe or other webhooks get accepted without a signature check, or point at a dev URL. None of these are hard to fix. They're just invisible until real users show up. If you've shipped an AI-built app, what broke first for you in production?   submitted by   /u/Ttd234 [link]   [comments]
- 情报分类:技术学习与提效
- 分类依据:内容涉及技术、AI、软件工具或工程实践
- 信息来源:Reddit · SaaS
- 发布时间:2026/10/21 05:04:00
- 暂无回复