You Built It in 3 Days. Now Your Infra Will Make or Break the Next 3 Months.

You opened Lovable on a Tuesday. By Thursday, you had something that looked like a real product with login screen, dashboard, a few functional flows. You showed it to a few people. Someone said "this looks great, can I actually use this?"

That question is where the prototype ends and the real work begins.

Because what you built fast, impressively fast is running on a set of infrastructure defaults that nobody made a conscious decision about. Supabase on the free tier. Vercel's hobby plan. Auth that handles email/password and nothing else. No file storage strategy. No background job handling. No security policies configured.

Those defaults are perfectly fine for a prototype. They become a serious problem the moment real people start using your product in ways you didn't anticipate.

This post is about the conversation that needs to happen between "I shipped a prototype" and "I have a production product." It's not about slowing down, vibe coding tools are genuinely useful and you should keep using them. It's about spending 30 minutes thinking before you prompt, instead of spending lakhs or Rs on a rebuild six months later.

The part of vibe coding that doesn't go viral

The clips are all about the build. Someone opens Bolt or Claude Code, describes a product in plain English, and in minutes there's a working UI with auth, a database, and deployed to a live URL. It's genuinely remarkable. Early-stage validation has never been cheaper or faster.

What doesn't go viral is what happens three months later.

A scan of 1,645 applications built on Lovable in May 2025 found that 170 of them, roughly 10% were actively leaking sensitive user data, including names, emails, and financial information. The root cause in most cases: Supabase was connected without Row Level Security enabled. The tools defaulted to open. Nobody flagged it. The founders weren't careless, they just didn't know what they didn't know.

That same year, a dating safety app left its Firebase instance running on default settings and exposed 72,000 images, including 13,000 government ID photos and 59,000 private messages. In February 2026, an AI-powered social network had a misconfigured Supabase database expose 1.5 million API keys and 35,000 user emails.

Again not bad founders. Founders who moved fast and treated infrastructure as something to figure out later.

The problem isn't vibe coding. The problem is assuming that the defaults that got you to a working prototype are the same defaults you want running when real users trust you with real data.

What "default infrastructure" actually gets you

Most vibe coding tools converge on a broadly similar stack: Next.js deployed on Vercel, Supabase for the database and auth, sometimes Cloudinary for image handling. It's a reasonable starting point. But each piece has constraints that are worth understanding before you're already dependent on them.

Vercel is excellent at what it does, deploying fast, globally distributed, with a developer experience that's hard to match. The hobby tier is legitimately free and perfect for demos and early testing. The issue is how quickly costs can climb once you're running a live product. Serverless functions have execution time limits, which means anything that runs longer than a few seconds like report generation, file processing, API calls to slow third-party services doesn't belong there. Background job handling needs to be deliberately architected, not assumed. And at real scale, Vercel's pricing can surprise teams who didn't model it before they were committed. None of this is a reason to avoid Vercel. It's a reason to know what you're signing up for.

Supabase is genuinely one of the better things to happen to startup infrastructure in the last few years. It's Postgres which means you're working with a real database, not a proprietary data model you'll regret later. It's open-source, which means you can self-host if you need to. And the free tier gives you a real running start on auth, storage, and edge functions alongside the database.

What gets founders into trouble: Row Level Security is not configured by default. When AI coding tools connect Supabase to your app, they often don't set up RLS policies because that requires knowing what your data access rules are, and the AI doesn't know your business logic. This means your database is wide open at the application layer until you explicitly configure it. That needs to happen on day one, not as a cleanup task.

The other thing Supabase doesn't do well: complex multi-tenant architectures, deeply custom role-based access systems, or products where most of the complexity lives in business logic rather than data queries. If your product is CRUD-heavy with clear relational data, Supabase is a great fit. If it's not, you'll feel that mismatch.

Convex is worth understanding if your product has real-time data requirements live feeds, collaborative features, shared state between multiple users. Supabase has a Realtime feature, but Convex is built from the ground up around reactive data, which makes certain classes of product significantly cleaner to build and reason about. We've used it on a few client builds and the developer experience for real-time use cases is genuinely different. It's not the default for every product, but if your product is inherently collaborative or live, it's worth evaluating early rather than retrofitting later.

Authentication is almost always the most underspecified piece in a vibe-coded app. Supabase Auth covers email/password and OAuth well. But if your product has team accounts, org-level billing, role-based permissions, or any multi-tenancy, you'll hit the limits of Supabase Auth fairly quickly. Clerk handles all of that natively and integrates cleanly with most stacks. The time to make that call is before you've built 40 auth-dependent screens around one system.

File storage and uploads is the quiet one that trips up a lot of products. Supabase Storage is fine for straightforward cases. But if users are uploading anything substantial like documents, images, videos, you want a proper strategy: AWS S3 with CloudFront in front of it, storage policies configured, signed URLs for private files, and an explicit decision about what triggers processing versus what gets stored raw. This is not a complex setup but it needs to be intentional. Storing files in your database is never the answer.

The three questions that change everything

This isn't about slowing down. It's about spending 30 minutes before you start that saves you from a costly rewrite later. Three questions, answered honestly, before your first prompt.

1. What does your data model actually look like?

Is your data primarily relational, users, records, structured entities with clear relationships between them? Postgres and Supabase are a strong fit. Is it document-shaped, or do you expect the schema to shift significantly as you iterate? You might want something more flexible in the early stages. Does it have real-time or collaborative requirements? That changes the backend choice entirely.

The AI tool will make a data model decision for you if you don't make it first. That decision is hard to change once you're in production. Spend ten minutes thinking about it.

2. What does this look like with 500 simultaneous users?

Not because you'll have 500 users on day one. But because the answer changes your hosting tier, your compute model, and whether Vercel serverless functions are appropriate or whether you need something with longer execution windows and persistent connections.

More importantly: does your product have work that takes more than a few seconds? Sending emails. Generating PDFs. Calling third-party APIs. Processing uploads. None of that should live in a serverless function. All of it needs a queue, a worker, or a background job system. If you don't have one, you'll either build fragile workarounds or face that gap at the worst possible time when real users are waiting.

3. Where does sensitive data live, and who can access it?

Before you write a single prompt, decide what's sensitive, where it lives, and what the access model is. Then make sure RLS policies and auth rules are built in from the start, not added as an afterthought after you've already been live for a month.

This one question, answered before you start, is what separates the apps that leak data from the ones that don't.

The migration trap and what it actually costs

Here's the pattern we see repeatedly. A founder vibe-codes an MVP on default infrastructure. It gets traction, real users, maybe some paying customers. Now the cracks show up: Supabase errors at 50 concurrent users, Vercel bills that doubled unexpectedly, auth that doesn't support team accounts, no proper file storage, security policies that were never set up.

The fix is a migration. And migrations are expensive.

Not just in money though rebuilding a vibe-coded codebase with proper infrastructure typically runs between $5,000 and $50,000 depending on scope and complexity. Expensive in time: weeks of engineering work that isn't product work. Expensive in risk: migrations break things, and breaking things on a live product with real users is a different category of problem than breaking things on a demo.

The money that goes into fixing avoidable infrastructure decisions is money that was supposed to go into growth, into the next feature, into hiring the next person.

And the painful part is that the right infrastructure decision at the start is rarely more expensive than the default infrastructure decision. It's just slightly more deliberate.

What an intentional stack looks like

For most early-stage products building on modern tooling, a solid foundation looks something like this:

Frontend and deployment: Next.js on Vercel is a reasonable default. If you're early-stage and cost predictability matters more than performance at the edge, Railway is worth comparing, more predictable pricing, persistent containers, better for apps with background work.

Database: Supabase/Postgres with RLS configured from day one. If you have real-time or collaborative requirements, evaluate Convex early. Don't let the AI tool make this call by default.

Auth: Supabase Auth for simple cases with email/password, OAuth, nothing complex. Clerk if you have team accounts, org-level billing, or role-based permissions. Make this decision before you've built screens around one system.

File storage: AWS S3 with CloudFront for anything production-grade. Supabase Storage for simpler cases where you're already in that ecosystem. Never in your database.

Background jobs: Even a simple queue if you have any async work. BullMQ on Railway, or a managed option like Trigger.dev or Inngest. The moment you have any work that runs longer than a couple of seconds, you need this and adding it later is significantly harder than adding it at the start.

That's not a complicated stack. It's just an intentional one. And the difference between a vibe-coded MVP that becomes a real product and one that gets rewritten six months later isn't the AI tool you used to build it, it's whether someone thought about infrastructure before the first prompt, or after the first incident.

Where BuildOrbit fits in this

We work with founders at a few different points in this journey.

Some come to us before they've started building, they've validated an idea and want to build it right from the beginning, with AI-assisted development and proper infrastructure underneath.

Some come to us after they've vibe-coded an MVP that got traction, they need it made production-ready, the architecture reviewed, the security gaps closed, the infrastructure upgraded for real load.

Some come to us mid-rebuild, after they've already hit the migration trap and need help getting out of it cleanly.

All three conversations start the same way: with your data model, your expected load, and the honest answer to "where does sensitive data live."

If you're at the prototype stage and want a starting point on what stack makes sense for your product, our Tech Stack Recommender gives you a directional answer based on your product type and scale. Free, takes about two minutes.

→ Try the Tech Stack Recommender

Or if you want to talk through a specific situation, lets talk