How to Move to Production Infrastructure
July 2026
When to use this: Your app is running wherever your AI coding tool defaulted to — a preview URL, a free tier on whatever platform it plugged into — and you're about to rely on it for real users without ever having made a deliberate decision about where it actually lives.
Why this matters
Prototype hosting is built to show you something quickly, not to run a real product. Free and starter tiers usually come with resource limits, no meaningful uptime guarantee, cold starts, and backup policies that were never designed with your data in mind. This isn't about your code changing at all — it's about making a deliberate decision about where the app runs, how it recovers when something fails, and who's actually accountable for it staying up.
Read what your current hosting actually promises
Check the fine print of whatever free or starter tier you're on: what happens under real load, is there any uptime guarantee at all, what's the actual backup policy for your database. Most founders have never looked at this because it was never the point of the tier they signed up for.
Decide if you need a new platform, or just a real tier on the one you have
A full migration isn't always necessary — sometimes the same provider has a production-grade tier, and the actual problem is that you're still on the free or hobby plan it defaulted to.
Make dev, staging, and production genuinely separate
Not the same deployment with an environment flag — separate resources, separate databases, separate credentials for each. This is the other half of the environment separation covered in secrets management, applied to infrastructure itself.
Set up real backups, and actually test restoring from one
A backup nobody has ever restored from isn't a verified backup — it's a hope that hasn't been checked. Run the restore before you need it for real.
Put a real domain and certificate in front of it, not a shared default subdomain
Beyond trust and appearance, this is about control — your product's availability shouldn't be tied to a subdomain you don't own on infrastructure you don't control.
Set resource limits and scaling deliberately
Know, in advance, what happens when traffic spikes — does it scale gracefully, queue requests, or simply fall over. Don't find this out for the first time during a spike.
Get monitoring and alerting in place before you cut over, not after
You want to know the moment something's wrong on the new infrastructure — not find out from a customer support message.
Cut over deliberately, with a rollback plan ready
Treat the move itself like any other production change: staged, reversible, watched closely as it happens — not a DNS change on a Friday afternoon followed by hoping nothing breaks.
Common mistakes
Never reading what the free tier actually guarantees. Its real limits get discovered for the first time under real load, at the worst possible moment.
Treating "a backup exists" as the same as "the backup works." Only a tested restore actually proves that.
Cutting over with no rollback plan. If the only plan is forward, a problem after cutover turns into a scramble instead of a quick, calm reversal.
Free Tool
Production Readiness Checklist — deployment is one of its 8 scored dimensions
Continue reading
Not sure how ready your infrastructure actually is? Run the Production Readiness Checklist →
TechTekGo Newsletter
AI engineering insights — from prototype to production.
No noise. Published when there's something worth reading.