From prototype to production — is your vibe-coded app actually ready to ship?

There's a particular kind of nervousness that comes after the demo works. It runs on your machine, it does the thing, and now you're wondering whether it'll survive contact with actual people. That nervousness is healthy, and the good news is that "production ready" is a much smaller, calmer idea than it sounds.

It does not mean perfect. It does not mean enterprise-grade, or built to handle a million users, or hardened against every threat. For a vibe-coded app shipping to its first real audience, production ready means one thing: it keeps working when real people use it in ways you didn't plan for, without losing their data or leaking your secrets. Let me give you the actual checklist.

"Production ready" is smaller than you think

The phrase gets used to scare people into over-building. Ignore that. A prototype becomes production ready not by adding layers of infrastructure, but by covering a short list of things that genuinely hurt if you skip them.

The demo and the real thing differ in one way: in the demo, you're the only user, and you behave. Real users paste weird input, leave fields blank, refresh at the wrong moment, and arrive on a phone you didn't test. Getting ready is mostly about handling that, not about scale.

The five things that actually matter

Run your app against these. If they hold, you're ready enough to ship.

1. It handles real input. Try the empty form, the enormous paste, the emoji in the name field, the wrong file type. A prototype assumes good input; a production app expects bad input and doesn't fall over. You don't need to handle everything elegantly, you need to not crash.

2. Your secrets are safe. API keys, passwords, and tokens live in environment variables, never in the code and never in a commit. This is the one I'd never wave through. If a key has ever been committed, rotate it, because the history keeps it forever.

3. Data survives. If your app stores anything a user would be upset to lose, make sure it's in a real database or a persistent volume, not a container filesystem that gets wiped on the next deploy. Test it: add something, redeploy, check it's still there.

4. It fails gracefully. When something goes wrong, and it will, the user should see a clear message, not a blank page or a stack trace. A friendly "something broke, try again" is the difference between a user who waits and a user who leaves and tells people it's broken.

5. You can see when it breaks. If your app fails and you don't find out until a user emails you, you're flying blind. You don't need a fancy setup, even basic error logging you actually check is enough to start. The goal is simply to know.

Don't over-engineer the rest

Here's the trap on the other side: deciding you need to be ready for scale you don't have. You do not need load balancers, multiple regions, a queue, or Kubernetes to launch. A single small server handles far more real users than almost any launch receives, and adding that machinery early just gives you more things to break and understand at the worst moment.

Make it correct and safe first. Add scale when real usage actually asks for it, not in anticipation of traffic you're hoping for. The boring single-server version is the right answer for longer than you'd think.

Ship to a forgiving audience first

The calmest way to cross from prototype to production is not to open the floodgates. It's to ship to a small, friendly group first, people who'll forgive a rough edge and tell you about it instead of leaving quietly. You find the real-world problems your demo never surfaced, with the stakes low, and widen once it holds.

That's exactly what Shipyard is for: a place to ship your app to other builders who'll give it honest feedback before the wider world piles on, so you find the production problems among people who want you to succeed. We're opening the first 50 founding spots now. If you're standing at the edge between prototype and production, come and ship it with us.