Backend for a Vibe Coded App: The Practical Guide

I've been vibe-coding since before it had a name. I've hit every wall you're about to hit, and I've got the abandoned project folders to prove it. Your AI agent can generate a beautiful frontend in minutes. It'll spit out a landing page that looks like a Fortune 500 company built it. But that login form? That contact page that's supposed to save submissions? That's where most vibe-coded apps die on the vine. If you're searching for a backend for a vibe coded app, you've already discovered the hard truth: Cursor and Claude are phenomenal at HTML and CSS, and genuinely terrible at anything that requires data to survive a page refresh. This article is the practical, battle-tested workflow I use to add real backend capabilities to AI-generated apps without abandoning the vibe-coding approach that got me 90% of the way there in the first place.

Table of Contents

• The Vibe-Coding Lie (and Why Your App Needs a Backend)
• What a Vibe-Coded Backend Actually Needs
• The Two Paths to Adding a Backend
• Step-by-Step: Adding a Database to Your Vibe-Coded App
• Step-by-Step: Adding Server Functions to Your Vibe-Coded App
• The Hidden Costs of "Free" Backend Tiers
• How to Hand Off a Vibe-Coded App to a Client (Without Embarrassment)
• Real Talk: When NOT to Vibe-Code a Backend
• The Stack I Actually Use in 2026
• Quick Reference: Backend Options Compared
• Your Next Move

The Vibe-Coding Lie (and Why Your App Needs a Backend)

AI agents generate stunning UIs with zero persistence. Refresh the page and every form field, every saved preference, every piece of user data vanishes into the ether. That's not a bug in your prompt. It's a fundamental limitation of what these tools output by default: static HTML, CSS, and client-side JavaScript that lives entirely in the browser's memory.

Most "deploy from AI" tools compound this problem by giving you a static URL that can't handle form submissions, user accounts, or dynamic content. You get a pretty preview link that expires in a week, which is useless when a client asks for the live site. The real bottleneck in vibe-coded projects isn't frontend polish. It's backend infrastructure that actually works when you hand the site to someone who isn't you.

The most common failure mode I see: a developer builds a "full-stack" app in Cursor, gets it running locally with SQLite and Express, then discovers nothing works in production because there's no real database server, no deployed API routes, and no environment for those server-side dependencies to run in. Local success is not production success. The gap between the two is a backend that exists outside your laptop.

What a Vibe-Coded Backend Actually Needs

A Real Database (Not Local Storage)

SQLite in the browser dies on refresh. LocalStorage is a key-value closet, not a database. If your app needs to remember anything between visits, you need persistent storage: Postgres, Cloudflare D1, or something comparable that lives on a server and survives restarts. Your AI agent can generate a perfectly valid schema, but it needs a real endpoint to connect to. The key question when evaluating any backend solution: does it provision a database per project automatically, or are you stuck wiring up a separate service, managing connection strings, and debugging CORS policies at 11 PM?

Server-Side Logic That Survives Deployment

Edge functions or serverless functions handle API routes, webhooks, auth checks, and anything that shouldn't run in the user's browser. Your AI-generated Express routes need to run somewhere that isn't your laptop. The code is probably fine. The deployment target is the problem. Watch out for cold starts on free tiers that add 3-second delays to every request, and execution time limits that kill long-running operations mid-stream.

A Permanent URL (Not a Preview Link)

Many AI deployment tools give you expiring preview URLs. Those are fine for showing a friend, useless for client handoff. You need a permanent URL with custom domain support and auto-DNS so you can point clientname.com to the app without manually configuring A records. SSL should be automatic. Your clients should never see a "Not Secure" warning because someone forgot to renew a certificate.

The Two Paths to Adding a Backend

Path A: Bolt-On Backend (Separate Service)

This is the Supabase, Firebase, or PocketBase approach. You vibe-code a frontend, deploy it somewhere, then connect it to a standalone backend service that handles auth, database, and storage. Supabase gives you Postgres and edge functions. Firebase gives you Firestore and Google's ecosystem. PocketBase gives you SQLite and a Go backend you can self-host for free.

The pros are real: these services are battle-tested, have generous free tiers, and their documentation is good enough that AI agents can reference it when generating integration code. The cons are equally real: you're managing two separate deployments, debugging CORS issues when your frontend domain doesn't match your API domain, and praying you don't wake up to a surprise bill because a webhook loop triggered 2 million function invocations overnight. This path works best for prototypes, MVPs, and apps where you control both sides of the equation and have time to monitor usage.

Path B: All-in-One Platform (Backend Built Into Deployment)

Platforms like Shiply take a different approach. One deploy command from your AI agent provisions a database, edge functions, and a permanent URL. No separate services to wire up. No connection strings to manage. The database is per-site, not per-account, which matters when you're handing off to a client.

The flat pricing model eliminates the anxiety that comes with metered billing. You pay $8 or $24 per month, period. No usage meter. No midnight alerts about exceeding function invocation limits. Atomic ownership transfer means you can move the entire site, database, domain, and billing to a client in one action via Stripe Connect. This path works best for freelancers shipping client sites and solo builders who want predictable costs and clean handoffs without infrastructure drama.

Path C: Full-Stack Framework (Wasp, Redwood, Adonis)

Opinionated frameworks structure both frontend and backend in a way that AI agents produce cleaner, more consistent code. Wasp, for example, gives the LLM a defined pattern to follow: Prisma for data modeling, a built-in auth system, and a clear separation between queries and actions. AI generates better code when it has guardrails.

The trade-off is a steeper learning curve and framework lock-in. If Wasp changes its API or you need something it doesn't support, you're rewriting. This path works best for larger projects, teams, and developers who want traditional control with AI assistance rather than pure vibe-coding speed.

Step-by-Step: Adding a Database to Your Vibe-Coded App

Step one: tell your AI agent to generate the schema first, not the UI. Prompt it with something like "Create a Postgres schema for a booking app with tables for users, appointments, and services. Include foreign keys and timestamps." Get the data model right before you build anything that depends on it.

Step two: provision a real database. If you're using a platform like Shiply, this happens automatically when you deploy. If you're going the bolt-on route, create a Neon Postgres or Supabase project and grab the connection string.

Step three: inject that connection string into your AI agent's context. Most agents will auto-generate the ORM code or query functions once they know where the database lives. Claude and Cursor both handle this well when given a clear target.

Step four: test locally with a mock database, then deploy to production with the real connection string. Don't skip the mock step. Catching schema errors locally saves hours of debugging against a live database.

Step five: verify persistence by refreshing the page, closing the tab entirely, and coming back. If your data survived that gauntlet, you've got a real backend.

Step-by-Step: Adding Server Functions to Your Vibe-Coded App

Prompt your AI agent to generate API routes as separate function files, not inline in the frontend code. A clean structure might be /functions/submit-form.js or /api/contact.ts. Separation makes testing and debugging far easier than hunting through a 2,000-line component file.

Use platform-specific function handlers. If your host runs on Cloudflare Workers, write for that runtime. If it's Node.js, use Express or a lightweight router. The AI agent needs to know the target environment to generate compatible code.

Start with three essential functions: a form submission handler that writes to your database, a user auth endpoint that validates credentials, and a data validation middleware that sanitizes inputs before they hit your database. Everything else builds on these foundations.

Test functions independently before wiring them to the frontend. Curl your endpoint first. Check the response. Verify the database write actually happened. Frontend integration is the last step, not the first.

Watch for execution time limits. Vibe-coded functions often contain inefficient loops or unoptimized queries that run fine locally but time out on production infrastructure with 10-second limits. If a function takes more than a second, ask your AI agent to optimize it.

The Hidden Costs of "Free" Backend Tiers

"Free" databases often throttle after 500 rows or 1GB of transfer. That's fine for testing, dangerous for client handoff. I've seen a client's contact form stop working because the free Supabase tier hit its row limit and silently rejected inserts. The client assumed the site was broken. I assumed everything was fine. Nobody was happy.

Metered functions charge per invocation. A single webhook-heavy app, a form that triggers email notifications, an API endpoint that gets crawled by a bot, can run $50 or more per month unexpectedly. The bill arrives after the damage is done.

Preview URLs expire after 7 to 30 days. That client demo you sent three weeks ago? Dead link. The investor who finally clicked through? 404. These aren't edge cases. They're the normal experience of building on free tiers.

The real cost isn't the monthly fee. It's the time spent migrating when you outgrow a free tier, the embarrassment of broken client demos, and the 2 AM panic when a usage alert hits your phone. Flat-rate hosting at $8 to $24 per month eliminates surprise bills and lets you sleep through traffic spikes. You can run the numbers yourself with a hosting bill calculator to see how metered costs compound against flat pricing for your specific usage patterns.

How to Hand Off a Vibe-Coded App to a Client (Without Embarrassment)

Atomic ownership transfer is the cleanest way to exit a project. Move the entire site, code, database, and domain to the client in one action. No exporting SQL dumps. No transferring DNS records one by one. No shared credentials where the client accidentally deletes your other projects.

The client gets their own login. They never see your personal account, your other client sites, or your admin panels. This sounds obvious, but most platforms weren't built for this workflow. They assume one developer, one account, many projects. That model breaks when you have ten clients who each need access to their own site.

Bill passthrough via Stripe Connect lets clients pay the host directly instead of reimbursing you. You're not a billing middleman. You're not chasing invoices. The hosting cost transfers with the site ownership.

Generate a simple "how to update content" document from your AI agent. Yes, you can vibe-code the handoff documentation too. If the client can log in, change a setting, and see it persist without calling you, the handoff is complete. That's the test.

Real Talk: When NOT to Vibe-Code a Backend

Real-time features like WebSockets and live collaboration are still painful with AI-generated code. The error handling is brittle, reconnection logic is often missing, and debugging race conditions in vibe-coded WebSocket handlers will make you question your career choices.

Complex auth flows with OAuth across multiple providers or role-based permissions with nested access rules often need manual tuning. AI agents generate auth code that looks correct but misses edge cases: expired tokens, refresh flows, permission inheritance. These failures are silent until a user reports they can't access something they should.

High-traffic apps need performance testing that vibe-coded backends rarely get. Your AI agent won't run load tests. It won't identify the N+1 query that melts your database at 500 concurrent users. If you're building something that expects real traffic, plan for a performance audit by a human.

Compliance requirements like HIPAA or SOC2 demand infrastructure control and audit trails that most AI tools and platforms can't provide. Don't vibe-code anything that handles protected health information or financial data subject to regulatory scrutiny.

The honest answer: vibe-code the prototype. Ship it to validate the idea. Then plan to rewrite the backend properly for production-critical applications. The prototype proves what to build. The rewrite makes it safe to run.

The Stack I Actually Use in 2026

Frontend: AI-generated with Claude and Cursor, using whatever framework fits the project. React for complex UIs, Svelte for lightweight sites, plain HTML when that's all the client needs. The AI handles all of them competently.

Backend: Shiply for database, edge functions, and deployment. One call from the AI agent provisions everything. Flat $8 per month, no usage meter, no midnight panic attacks about a traffic spike blowing up my bill. The database is provisioned per site, which makes client handoff trivial.

Domain: Cloudflare for DNS, auto-configured by the platform. I don't touch A records or CNAME flattening anymore. It just works.

Database: Cloudflare D1 for SQLite-compatible workloads, Neon Postgres when I need full relational power. Both provisioned automatically per site, not shared across projects.

Form handling: Built-in site data capture with an inbox for submissions. Clients can log in and see their form entries without me building an admin panel.

Client handoff: Atomic ownership transfer via Stripe Connect. The client pays the host directly. I walk away with a finished project and no ongoing billing relationship to manage.

Before committing to any stack, I run the numbers through a hosting bill calculator to compare flat versus metered costs. The difference between a $8 fixed monthly and a variable bill that might hit $80 is the difference between a sustainable freelance business and a hobby that costs money.

Quick Reference: Backend Options Compared

Tool	Database	Functions	Pricing Model	Best For
Supabase	Postgres	Edge Functions	Metered (free tier)	Full control, complex apps
Firebase	Firestore	Cloud Functions	Metered (pay per use)	Google ecosystem, real-time
Shiply	D1 + Postgres	Workers Lite	Flat ($0-$49/mo)	Freelancers, client handoff
Wasp	Prisma + SQL	Node.js	Self-hosted or managed	Full-stack frameworks
PocketBase	SQLite	JS/Go	Self-hosted (free)	Simple apps, no budget

Your Next Move

Pick one path from this article and build a single-function backend today. Not a full app. Just a database write and a database read. A form that submits a name, saves it, and displays it back. That's it.

Test it with your AI agent. Prompt it to generate a form that submits to your new backend endpoint. Deploy it to a permanent URL. Refresh the page. Close the tab. Open it again. If the data persists, you've cracked the fundamental problem that separates vibe-coded demos from real products.

The difference between a demo and a product is a backend that survives a browser refresh. You're one deploy away from crossing that line.