Choosing a real stack once your AI-generated prototype actually works

Your AI-generated prototype works, people want it, and now everyone has an opinion about what you “should have” built it on. Next.js, Postgres, Supabase, a different host, a rewrite. The advice is loud and contradictory, and most of it is really about what the advisor likes, not what you need. Here’s a framework for choosing a stack based on your actual situation instead of the loudest voice.

First rule: don’t rewrite just because it works now

The instinct after a prototype succeeds is to throw it away and “do it properly.” Resist that. A rewrite is the most expensive, slowest, riskiest move available, and it often ships a worse product because you rebuild the bugs you’d already fixed. Change your stack when the current one is actually blocking you, not because a working prototype feels too casual to keep. The bar for a rewrite is high: name the specific thing that’s broken and can’t be fixed in place. If you can’t, don’t rewrite.

The framework: answer these before you choose anything

Stack decisions get easier when you stop asking “what’s best” and start asking “best for what.” Work through these in order.

1. What’s actually breaking or blocking you right now?

Be concrete. Not “it feels fragile,” but a specific problem:

• The database runs out of connections when a few people use it at once.
• You can’t get a real backup, or can’t control retention.
• The platform’s monthly cost jumps sharply as you grow.
• You need EU data residency and your current host can’t give it.
• You’re hitting a hard limit (row count, storage, request rate) you can’t raise.

If nothing on this list is true, you may not need a stack change at all. Harden what you have and keep shipping. The best stack decision is often “not yet.”

2. Who will maintain this in six months?

This drives more of the decision than any technical merit.

• Just you, non-technical: favor managed everything. Fewer moving parts you have to understand. A platform that handles hosting and database, plus a managed backup, beats a powerful setup you can’t operate.
• You, and you can code: you can take on more control (your own Postgres, your own host) in exchange for lower cost and no lock-in. But be honest about how much ops you want to do at 2am.
• A team or a hired developer: pick boring, common technology they’ll actually know. A stack that’s popular and well-documented is worth more than a clever one only one person understands.

Match the stack to the operator, not to the architecture blog.

3. What does your data actually need?

The database is the part you can’t afford to get wrong, because it holds the thing you can’t regenerate: your users’ data.

• Anything real (users, orders, bookings): you want Postgres, tested backups, and point-in-time recovery. This is non-negotiable for a business.
• EU personal data: add data residency and a DPA with whoever hosts it.
• Toy or internal-only: you can be more relaxed, but “internal tool” has a way of becoming “the thing the business runs on.” Assume it’ll matter and you won’t get caught out.

Decide the database story first. Everything else is easier to change later; your data is not.

4. How much lock-in can you live with?

Every convenient platform trades control for lock-in. That’s a fair trade until it isn’t.

• All-in-one platforms (the app builder also hosts and runs your database) are fastest to start and hardest to leave. Fine early, painful if pricing or limits turn against you. See app-builder lock-in for the traps.
• Portable pieces (your code in a normal Git repo, standard Postgres, a host you can swap) cost a bit more effort up front and save you when you need to move.

The test: could you leave this platform in a week if you had to? If the honest answer is “no, we’d be stuck,” weigh that against how convenient it is today.

5. What can you actually afford, in money and attention?

Two budgets, and people forget the second one.

• Money: managed services cost more per month but less of your time. Self-hosting is cheaper in cash and expensive in hours.
• Attention: every service you run yourself is something you have to monitor, patch, and fix. For a solo founder, attention is the scarcer budget. Spend money to protect it.

Putting it together: three common paths

Based on the answers above, most people land in one of three places.

• Stay and harden. Nothing’s truly blocking you, you’re non-technical, and the platform is fine. Keep the app where it is, add real backups and monitoring, fix secrets and access rules. Cheapest and least risky. Most people who think they need a new stack actually need this.
• Keep the code, move the data. The app’s fine but the platform’s database is the bottleneck (connection limits, no PITR, EU residency). Move to managed Postgres you control, leave the rest. A targeted change, not a rewrite.
• Portable stack. You’re growing, lock-in is a real risk, and you (or your team) can operate more. Code in a normal Git repo, your own Postgres with tested backups, a host you can swap. More setup, more control, no one holding your business hostage.

Notice none of these is “rewrite from scratch.” That path exists, but it’s rare and it’s a last resort.

Or, we do it for you

If you’ve worked through the framework and landed on “keep the code, move the data” or “I don’t want to run any of this myself,” that’s exactly the job we do: your app on your own Postgres with tested backups and PITR, monitored, with a named human on call. Start with a free audit and we’ll tell you honestly whether you need a stack change at all, or just some hardening where you are.

FAQ

Everyone says I should rewrite in Next.js. Should I?

Almost certainly not, if the reason is “it’s more professional.” Rewrite only when a specific, named problem can’t be fixed in your current stack. “The framework isn’t trendy” is not that problem. A working prototype has real value: it’s tested by real users and it ships revenue. Throwing it away to rebuild the same features in a fancier framework usually costs months and buys nothing your users can feel.

Is it bad to stay on my AI builder’s platform long-term?

Not inherently. Staying is fine as long as the platform meets your needs and the lock-in doesn’t scare you. It becomes a problem when you hit a hard limit, the pricing turns against you at scale, or you need control the platform won’t give (backups, EU residency). The signal to move isn’t a feeling, it’s a specific wall you’ve hit. Until then, harden where you are.

How do I pick a database if I’m not technical?

Default to managed Postgres with tested backups and point-in-time recovery, and let someone else operate it. Postgres is the boring, proven, widely-supported choice, which is exactly what you want for data you can’t afford to lose. The technical decision that matters most isn’t which database, it’s whether your backups actually restore. Get that right and the rest is detail.

What if I choose wrong?

Most stack choices are reversible if you kept your code portable and your data in standard Postgres. That’s the real hedge: not picking perfectly, but staying able to move. The one choice that’s genuinely hard to undo is losing data you never backed up. Get backups and portability right, and a wrong stack pick becomes a migration you can do later, not a disaster.