The Serverless Lie: Why Your Next.js App Will Cost You
If you spend any time on tech Twitter, you've seen the stack: Next.js, Supabase, Tailwind, Vercel. Ship fast, scale infinitely, pay only for what you use. Except that last part is a lie that reveals itself the moment you get actual users.
Let me be clear: I'm not anti-Next.js. Hackathon with 48 hours? Fresh off rewatching The Social Network? Ship that Next.js app. But defaulting to it for everything? That's not engineering, that's herd mentality.
What Serverless Actually Means
Serverless doesn't mean no servers. It means you're not managing them. AWS, Google, or Azure handles that while you write backend code that's now mysteriously coupled to your frontend in a meta-framework that does both client-side and server-side rendering.
This isn't better architecture. Backend and frontend should be separated. Full stop.
When Serverless Actually Works
Credit where it's due. Serverless shines for:
- IoT and lightweight apps where a dedicated backend is overkill
- Simple CRUD MVPs testing product ideas without heavy database dependencies
- Edge functionality when you need code closer to users (cold starts willing)
But these are specific use cases, not a default architecture.
The Real Cost of Serverless at Scale
Here's what Tech Twitter won't tell you: that "pay only for what you use" model flips fast. At a million requests, dedicated servers crush per-request billing. Long-running or high-throughput apps get expensive quickly.
Vercel's serverless functions have a 250MB bundle size limit and 60-second timeouts. Great for toy apps. Terrible for anything serious you're putting in front of users. Cold starts can hit multiple seconds depending on runtime. Your first 10 concurrent users might choke your app.
The Better Architecture
I build backends properly: FastAPI with Python, PostgreSQL, Pydantic schemas. Deploy on Render or my own VPS. Frontend is React with Vite and React Query for API calls.
Yes, two different languages. Yes, it goes against the "one language for everything" gospel. But here's what you get:
Separation of Concerns
Deploy independently. Fix issues in isolation. No redeploying your entire app because one component broke in your coupled meta-framework.
Actual Scalability
When your app somehow goes viral, you can add background tasks, queues, API gateways, load balancers. Try doing that with Vercel's architecture.
No Vendor Lock-in
Migrate anywhere. Move in-house to your own VPS. Control your costs. At scale, predictable fixed-cost compute beats per-request billing every time.
Real Processing Power
Build projects that need actual resources without hitting bundle limits or timeout walls. Vercel is optimised for JavaScript frameworks, not Python backends.
The TypeScript Defence
Before you attack Python's typing: FastAPI enforces types at runtime using Pydantic. Python supports type hints. My backend has defined schemas. It's production-safe.
TypeScript has the most insane PR of any language. Doesn't make it the only valid choice.
The Bottom Line
I architect systems based on principles, not trends. If you can afford a Claude Max subscription, you can afford a VPS.
Serverless has its place. But coupling your frontend and backend because everyone on Twitter is doing it isn't architecture. It's technical debt with a viral marketing budget.
Ship what makes sense for your use case. Not what gets likes.