Dev Builds, localhost URLs and Lorem Ipsum: What Ships to Production by Mistake

AI coding tools are very good at getting an app to run. They are less careful about the difference between "runs on my machine" and "ready for strangers". The result is a family of leftovers that never cause an error, so nobody notices them, but each makes the site slower, less trustworthy or leakier. Here are the seven most common, and how to check for each.

Why do AI-built apps ship these leftovers so often?

None of these are mistakes a careful team makes on purpose. They come from how AI-assisted development works in practice. The assistant’s goal in each session is to make the current thing work, and every item on this list is something that makes a thing work during development: a dev server that reloads instantly, a localhost fallback so the app runs without configuration, filler text so a layout can be judged, a log line to trace a bug. Nothing prompts anyone to undo them, because nothing is broken.

Traditional teams catch this with a release process: a staging review, a checklist, a colleague who asks why the footer says "Your Company". A solo founder shipping from a chat window usually has none of that. The fix is not to slow down but to add one deliberate pass between "it works" and "it is live", which is what the rest of this article is.

1. How do I know if my site is running a development build?

The usual cause is a host where you start the app with a command, such as a VPS, Replit or a container, and the command is npm run dev because that is the one that worked during development. A dev server skips minification, includes debugging code, rebuilds on the fly and often shows detailed error overlays to every visitor.

• View source and look for /@vite/client or @react-refresh. Both are Vite dev-server modules and never appear in a production build.
• Open DevTools. React DevTools shows a red icon for a development build, and the console fills with React warnings that production builds strip out.
• In a Next.js app, next dev adds a small indicator in the corner of the page and serves unminified chunks.
• Check your start command. package.json should run next start, node server.js or a static file server after npm run build, not dev.

2. API calls to localhost

This one breaks features for every real user while working perfectly for you, because on your machine localhost:3000 is your API. The usual source is a fallback in the code:

// Works locally. In production, if API_URL was not set at BUILD time,
// every visitor's browser calls their own computer.
const API = process.env.NEXT_PUBLIC_API_URL || 'http://localhost:3000'

Browser-exposed environment variables are baked in when the app is built, not when it starts. If the variable was missing on the build machine, the fallback is compiled in permanently. Search your build output for localhost: and 127.0.0.1, and prefer failing the build loudly over a silent fallback.

3. Links to staging and preview environments

The same mechanism with a different URL: an API base pointing at staging.yourapp.com or a *.vercel.app preview deployment. Production users end up writing to a staging database, or a preview deployment with weaker protection is advertised to anyone reading your JavaScript. Grep the build for staging, preview, dev. and your platform’s preview domain.

4. Placeholder content and scaffold branding

Lorem ipsum in a features section, "Your Company Name" in the footer, hello@example.com as the contact address, a testimonial from "Jane Doe", or the tab title still reading "Vite + React". Visitors notice these immediately, and they read as "this business is not real". Search the rendered pages, not just your components, because placeholder text often lives in a CMS or a config file.

5. console.log statements with user data

Debug logging is how assistants trace a bug, and the logs stay after it is fixed. console.log(user) or console.log(response) in browser code prints tokens, email addresses and API responses into the console of every visitor’s browser, and of every browser extension watching it. Strip them at build time and use a proper logger on the server:

// next.config.js — remove console.* (except errors) from production client bundles
module.exports = {
  compiler: {
    removeConsole: { exclude: ['error'] },
  },
}

6. Error pages that show a stack trace

A development error page is designed to be as helpful as possible, to you. In production it tells visitors your framework, file paths, library versions and sometimes query text. Framework production modes hide this by default, so a stack trace in production usually means a dev build (see point 1) or a custom error handler that returns err.stack in the response.

7. A 404 page that returns 200

Single-page apps often answer every unknown URL with the app shell and a 200 OK, then render "Page not found" in the browser. Search engines see a successful page and may index thousands of empty URLs. Your missing pages should return a real 404 status. Check with curl -sI https://yourdomain.com/this-does-not-exist, and see canonical tag mistakes that hide pages from Google for the other common way a new site confuses search engines.

A five-minute pre-launch check

npm run build

# Next.js: .next/static   Vite: dist
grep -rEl 'localhost:[0-9]+|127\.0\.0\.1|staging\.|\.vercel\.app|lorem ipsum' .next/static dist 2>/dev/null
grep -rc 'console.log' .next/static dist 2>/dev/null | grep -v ':0$'

curl -s https://yourdomain.com | grep -E '@vite/client|react-refresh'
curl -sI https://yourdomain.com/this-does-not-exist | head -1

While you are there, check that no secrets shipped alongside the leftovers. A deployment that serves a dev build is often also serving the project folder, which is how an exposed .env file happens.

How UseShipReady finds production leftovers

UseShipReady reads each crawled page and the JavaScript it loads, and reports a development build served to real visitors, a production build pointing at localhost and references to a staging or preview environment. It only counts markers in code the page actually runs, so an article quoting a dev warning, like this one, is not reported.

The same scan covers placeholder content, unedited scaffold branding, JavaScript that logs sensitive data, stack traces on error pages and pages that say not found but return success. The full launch list is in the production readiness checklist.