The Vibe Coding 'Go-To Stack': Next.js + Supabase – Misconceptions and Truths
The Next.js and Supabase combination suggested by AI is useful for quick prototyping, but in production, hidden limitations emerge. This article examines the reality behind the illusion of a complete app, including cost explosions, vendor lock-in, and learning curves, and provides insights for wise stack selection.
Next.js and Supabase are the ‘national stack’ that many vibe coding tools suggest, but this combination is not optimal for every project. While they are ideal for building a rapid prototype, you may encounter unexpected costs and structural limitations when dealing with complex business logic or traffic surges. This article uncovers the truths hidden behind stack decisions and aims to help you make context-aware, wise choices instead of uncritical acceptance.
How the ‘National Stack’ Was Born: The Brain Image of AI Recommendations
In recent years, AI coding tools like Claude, Cursor, and v0 have been doling out the advice “Start with Next.js and Supabase” almost as a default. One developer shared that when building a recipe app, the AI suggested “Use Next.js 14 server actions, Supabase backend, Tailwind, and shadcn/ui.” This is because it presents a ‘ready-made path’ that even beginners can easily follow. However, this is more akin to the AI repeating the most frequent pattern from vast training data, rather than reflecting the unique requirements of your project.
A Working Prototype Is Not a Finished App: The Perception Trap
Non-developers or those just starting to code easily think “the app is complete” when they see a functional prototype. As Roy Derks pointed out, the biggest problem with vibe coding is perception. Even an app that looks flawless on the surface may harbor production flaws like security vulnerabilities, lack of scalability, and incomplete transaction handling. For instance, many cases implement user authentication simply with Supabase Auth but completely neglect granular access control (RBAC) or session management. Such gaps can only be spotted by experts with technical insight.
The Shadow of Serverless Magic: Realistic Costs and Performance of Realtime and Edge Functions
Supabase’s realtime subscriptions and Edge Functions are fantastic for building demo apps. However, as concurrent users exceed a few hundred, the number of channels and message frequency for realtime subscriptions grow exponentially, causing costs to skyrocket. Edge Functions also operate in a restricted Deno-based environment, so you often cannot use Node.js ecosystem dependencies as-is. Even Supabase’s official documentation recommends “Use Web APIs and Deno core APIs instead of external dependencies.” If you need to handle complex business logic, serverless can actually distort your design and make debugging more difficult.
App Router and Server Actions: High Hurdles Behind Productivity
Next.js’s App Router and Server Actions certainly boost productivity. However, React Server Components, client boundaries, caching strategies, and data fetching patterns demand a significant learning curve even for experienced Next.js developers. One developer who completed an 8-month project with Next.js and Supabase lamented, “After deploying to Vercel, there were many long-term maintenance aspects to manage.” Even if things start quickly, as features are added, the maintenance burden grows in areas like server-client role separation, error boundaries, and deployment pipeline optimization.
Vendor Lock-in and Billing Bombs: The Price of Depending on Vercel and Supabase
Vercel and Supabase expertly abstract hosting and backend respectively, but this leads to a strong vendor lock-in. For example, Vercel’s edge functions use their own runtime, and Supabase’s storage and realtime APIs make migration extremely tricky. Even a slight increase in traffic beyond expectations often results in billing bombs due to serverless function execution limits or database connection pool limits. In fact, community complaints like “I got billed $500 from Vercel” are not hard to find.
Becoming a Savvy Vibe Coder: Alternative Stacks and Prompt Engineering
The true value of ‘vibe coding’ lies in fast experimentation. Therefore, it is wise to flexibly choose the stack according to the nature of the project. For example, for an offline-first app, you might consider local-first tools like SQLite or PouchDB; for a simple API server, Hono or Fastify could be ideal. Also, when prompting AI, adding instructions like “For a simple prototype, use Next.js+Supabase, but include an abstraction layer so we can later switch to direct PostgreSQL connection” can secure scalability from the start. Ultimately, understanding the pros and cons of tools and adopting them critically is crucial.
Conclusion
Next.js and Supabase are certainly powerful tools, but they are not magic wands that solve every situation. Even in the flow of vibe coding, we need to cultivate an eye for discerning the essence of technology. Imagining beyond the prototype and reviewing code with your team to uncover hidden flaws is the true path to building a real product. For such collaboration and history management, using a human-in-the-loop review tool like md-log can be a great way. In the end, the stack is merely a means to realize the project’s purpose, and it should not be the master that leads us.
References
Frequently asked questions
- Do I have to use Next.js and Supabase for vibe coding?
- No. While AI tools often recommend them as defaults, there are more suitable alternatives depending on the project's scale and requirements. For example, a lightweight static site might be better with Astro, and a real-time collaboration app could use Elixir/Phoenix. Stack selection should always be approached critically.
- Is Supabase stable enough for production use?
- Supabase provides sufficient performance based on stable PostgreSQL, and many startups use it successfully. However, due to the nature of serverless architecture, costs can rise quickly with a spike in concurrent users, and complex transactions or RBAC require additional design. It is recommended to perform load testing before production.
- I've heard learning Next.js App Router and Server Actions is difficult. Are there alternatives?
- App Router has a steep learning curve, including React Server Components concepts. You can stick with the traditional Pages Router, or consider alternative frameworks like Remix. The important thing is to choose a framework considering your team's capabilities and the project's complexity.
- Can I keep using Next.js and Supabase while avoiding vendor lock-in?
- Yes. Since Supabase is compatible with standard PostgreSQL, you can migrate to another PG hosting anytime. You can also deploy Next.js using Docker or your own server instead of Vercel. However, if you rely on edge functions or Vercel-specific features, migration costs increase. The key is to design an abstraction layer early on to minimize dependencies.