What "full-stack" should mean in an AI app builder

"Full-stack" is the new headline feature for AI app builders. Almost everyone claims it now. But if you look at what actually gets generated, the word is doing a lot of quiet work — because for most tools, "full-stack" means "your frontend, plus a wire to a managed backend someone else runs." That's genuinely useful. It's also not the same thing as generating a backend, and the difference matters the moment your app needs to do something the managed service doesn't hand you for free.

What most tools mean by full-stack

Look at where the "backend" actually lives in the tools that offer it. Lovable generates a React frontend and connects it to Supabase — auth, a Postgres database, row-level security, storage, all hosted by Supabase. v0 leans on Next.js API routes and server actions, again typically with Supabase behind them. Bolt runs a real Node environment in the browser and can stand up API endpoints and a database, usually pointed at a managed provider on deploy.

These are good products and, to be clear, a managed backend is the right call for a lot of apps — you get auth, a database, and scaling without owning any of it. But notice what the generation step is really producing in each case: frontend code, plus configuration and calls against a backend platform. The server-side logic — your data model, your endpoints, your rules — is either thin or lives inside the managed service's conventions. When people say "the AI built my backend," what usually got built is the glue between a UI and a BaaS.

That's a reasonable scope. It's just worth being precise, because "generate a real backend" is a different job with different requirements.

What generating a real backend requires

Four things have to actually be produced — as code you own, not settings on someone else's platform:

A data model and a schema. Not "a Supabase table you clicked into existence," but a schema and migrations expressed in code, in your stack's idiom.

An API you can read. Real routes, real handlers, real status codes — a server you could open, understand, and change, rather than a set of auto-generated endpoints you don't control.

Somewhere it runs. A backend that only exists as a deploy-time artifact is hard to trust. Ideally you can see it respond while you're building, not only after you ship.

A path to production that's yours. The generated backend should deploy to infrastructure you control, talking to a database you own — not stay locked to the tool.

Skip any of these and "full-stack" quietly collapses back into "frontend plus a hosted database." The tell is simple: ask where the business logic lives. If the honest answer is "in the managed service," the tool generated an integration, not a backend.

How Shipd does this

Shipd generates the backend as code that lives in your project, in one of four stacks — Node/Express, Python/FastAPI, C#/ASP.NET, or Java/Spring Boot — each with a real data layer (Prisma, SQLAlchemy + Alembic, EF Core, or Spring Data JPA) and an environment-based DATABASE_URL so you connect your own database.

For a Node backend, we go one step further: it runs live in the preview. The generated backend/app.js is an Express app mounted as middleware inside the in-browser runtime, so your frontend calls a same-origin /api and gets real responses while you build — no deploy, no separate server, no CORS. The data layer is dual-mode: it uses an in-browser SQLite (via sql.js) in the preview, and switches to Postgres automatically when a DATABASE_URL is present. Publish it and Shipd wraps that same Express app as a Vercel serverless function — so the app you tested is the app that ships, backed by your Postgres.

Two honest caveats, because they matter. First: the live-in-the-browser experience is Node-only today. Python, Java, and C# backends generate as complete, runnable projects — with a README and run/deploy steps — but you run those outside the browser, because a WebContainer is a Node runtime. Second: a managed backend is still the right answer for plenty of apps, and if that's what you want, the other tools do it well. The reason to generate a real backend is ownership — you can read it, change it, run it anywhere, and you're not renting your server-side logic from a platform.

The test that actually matters

Ignore the "full-stack" label and ask one narrower question: where does the server-side logic live, and can you run it yourself? If your data model and endpoints are code in your repo — code you could open, understand, and deploy to your own infrastructure — that's a generated backend. If the "backend" is really a configured hosted service and a set of calls into it, that's a capable frontend builder with a database attached. Both are legitimate. They're just not the same product, and the difference shows up the first time you need your app to do something the platform didn't anticipate.

Try a full-stack build →