Backend + Frontend in One Prompt: Inside RapidNative's Fullstack Template

Most tools calling themselves an AI fullstack app builder generate a beautiful screen and stop there. You get a login form that never authenticates, a product list bound to a mock array, a cart that empties on refresh. The frontend was the easy part. The backend — the schema, the auth, the migrations, the row-level access rules — is where the illusion breaks.

RapidNative's fullstack template is built around a different bet: a single natural-language prompt should produce a real Postgres database, a real Supabase auth setup, seeded demo data, Row-Level Security policies, TypeScript types generated from the actual schema, and the Expo screens that consume them — in one continuous turn. And every one of those artefacts should be validated before a byte lands on disk.

This post is a walkthrough of how that actually works, why it's different from earlier fullstack AI templates, and what the architecture buys you as a builder.

Photo by Alvaro Reyes on Unsplash

What "fullstack" actually has to include

Before the mechanics, let's pin down the term. An honest AI fullstack app builder has to produce four things, not one:

1. A real database — persistent, queryable, with types the client can trust.
2. Auth — sign-up, sign-in, sessions, and a signed-in user object the queries can filter on.
3. Access control — rules the server enforces, so a compromised mobile client can't read other people's rows.
4. A frontend — screens that talk to the database using the same identifiers as the schema, not a hallucinated column that doesn't exist.

The failure modes are all correlated. If the schema is a JSON blob instead of migration files, you can't supabase db push to production. If auth is a UI illusion, RLS has nothing to filter on. If the frontend queries a table the schema doesn't have, the app runs green in the preview and 500s in prod.

The interesting engineering question isn't can the AI produce these — it's how does it stop them drifting apart.

The SQL-first shift

The earlier version of RapidNative's fullstack template — the one called fullstack-v2 — held schema in JSON records and generated a TypeScript layer on top. It worked for demo apps. It didn't survive real deployments, because the JSON was one abstraction away from what actual Postgres wanted, and the seed files were hand-written literals that couldn't express .map() or template strings.

The current template — fullstack-supabase — moves the source of truth into supabase/migrations/*.sql. That decision changes everything downstream:

• What the AI writes is what Postgres runs. No translation layer between them.
• The Supabase CLI works out of the box (supabase db push, supabase db reset, supabase migration new).
• Migrations are ordered by timestamp filename, the same way every Supabase project on GitHub is ordered.
• Seed data is a real SQL file, not a JavaScript literal that has to be serialized.
• You can hand the project to a backend engineer without translation.

This is one of those decisions that reads as boring on a landing page and pays for itself the first time a customer needs to migrate 800 rows from staging to prod. The reason it wasn't the first design is that it puts the AI on the hook for writing schema that a real database will actually accept.

That's the problem the rest of the architecture exists to solve.

Five database tools, and what each one enforces

The AI agent driving the fullstack template doesn't reach into Postgres directly. It calls tools. There are five of them, and each one has a specific job:

db_migration_new — the only way to change schema. The agent supplies a name and complete SQL. The tool timestamps the file (YYYYMMDDHHMMSS_name.sql in UTC), applies it to an in-memory Postgres on top of every prior migration, lints the result, and writes the file to disk only if validation passes. A broken migration never lands. This is important: without this gate, one bad CREATE TABLE can leave the project in a half-applied state where every subsequent tool call reports errors against a schema that doesn't fully exist.

db_seed — writes the complete supabase/seed.sql. Replaces the whole file, never appends. Validated the same way: applied on top of migrations in a throwaway engine, warned if seed rows are invisible to the demo user under RLS, and rejected if there are duplicate primary keys. The append-vs-replace distinction matters more than it sounds — every "why is my seed data duplicated four times" bug in a hand-written pipeline is an append pipeline.

db_tables — lists every table with column counts and RLS status. Cheap. The agent is told to call it before guessing what exists.

db_describe — full detail for one table: columns, types, nullability, indexes, RLS policies, triggers. Cheaper than reading the raw SQL file.

db_sql — read-only SELECTs, including against system catalogues. The agent can inspect its own work. Cannot modify anything.

The important detail is the read/write asymmetry. There is exactly one path that mutates schema (db_migration_new), exactly one that mutates seed data (db_seed), and three read paths. It's structurally impossible for the agent to change schema without going through the validated migration flow.

Photo by Markus Spiske on Unsplash

pg-mem: validating before writing

Migrations are validated against an in-memory Postgres before they land on disk. The engine is pg-mem — a fork the project uses because it supports the specific catalogue tables (nullability, defaults, foreign keys, referential_constraints, trigger views) that the linter needs to read.

Every read operation rebuilds a fresh Postgres instance from the migration files currently on disk. Migrations are applied in filename order (that's what the timestamped prefix is for). Seeds are deliberately not applied on the read engine — only migrations. Within a single request, the engine is cached so db_tables + db_describe + db_sql don't rebuild three times.

Three properties fall out of this design:

1. Files on disk are the source of truth, always. There's no in-memory state that can drift from what's stored.
2. A rejected migration never mutates the read state, because it's rejected before it's written, and the next rebuild sees the pre-attempt file set.
3. RLS is enforced, not stubbed. pg-mem now enforces Row-Level Security the same way real Postgres does. Setting the role and JWT claim actually filters rows. A superuser bypasses RLS — which is genuine Postgres behaviour — so the way you test a policy is to run the query as a user, not as the admin.

A minimal auth schema is created inside pg-mem — auth.users, auth.uid(), auth.role() — so migrations can reference auth.uid() and references auth.users(id) without special-casing. The demo user's UUID is fixed (00000000-0000-0000-0000-000000000001) so seeds are reproducible across runs.

Row-Level Security by default — enforced by the linter, not the prompt

A prompt that says "use RLS on every table" is a prompt an LLM will forget. So RLS-by-default is enforced by the tool layer, not the system prompt.

Every migration that creates a table is linted for two things:

• alter table X enable row level security; must appear.
• At least one policy on X must appear in the same migration.

If either is missing, the tool refuses the migration. There is no "we'll add the policy later" path. The reason isn't dogma — it's that RLS enabled + no policies is Postgres's worst-behaving state: it silently returns zero rows to every query, and the mobile app just looks broken with no error anywhere in the stack. It's the single worst class of bug you can ship into a customer-facing preview, and the linter is specifically calibrated to make it impossible to reach.

Other rules the linter enforces on every migration:

None of these are opinions. They're the failure modes real projects hit in the first month. Enforcing them at the tool layer means the AI can't skip them under length pressure or forget them in turn seven.

Types follow the schema

mobile/src/db/types.ts is regenerated after every migration. Never hand-edited. Never lagging.

The mobile app uses @supabase/supabase-js — the plain client, no wrapper. When the app calls client.from('workouts').select('duration_minutes'), the return type comes from the regenerated file. If duration_minutes doesn't exist on the schema, TypeScript fails at compile time in the preview. If it existed, then got renamed to minutes in the last migration, the compile fails immediately — you don't ship an app that queries dead columns until a user opens the screen.

The reason to auto-regenerate rather than let the agent "keep the types in sync" is that keeping types in sync manually is exactly the class of thing LLMs forget under load. The rule is: schema mutates → types regenerate. Not "the agent should remember to regenerate."

The Supabase docs describe the same pattern for hand-driven projects: generate types from the database, not the other way around. RapidNative just automates the regeneration on every migration.

The full stack you get when you download

A generated project has this layout:

mobile/
  app/               # Expo Router screens
    (app)/
      index.tsx
  src/
    db/
      client.ts      # @supabase/supabase-js
      types.ts       # regenerated after every migration
    hooks/
      useAuth.ts
      useApp.ts
  package.json
api/
  index.js           # Express server (for custom endpoints)
web/
  index.html         # Optional static web
supabase/
  migrations/
    20260804140001_create_workouts.sql
    20260804140002_add_rls_to_workouts.sql
  seed.sql
  config.toml
rapidnative.json

The mobile/ directory is a plain Expo app. The supabase/ directory is the exact layout the Supabase CLI expects. You can git clone, supabase start, npx expo start, and iterate locally. You can push to production via supabase db push and EAS Build. Nothing in the export is proprietary to RapidNative — it's just standard tooling.

Photo by Daniel Korpai on Unsplash

How a single prompt gets translated into all of this

The end-to-end flow for a prompt like "Build a fitness tracker with workouts, exercises, and a history log":

1. Prompt arrives at the streaming route. The system prompt has been computed once at module load, byte-identical across every request. That static prefix is what enables DeepSeek's prefix caching — cached tokens cost roughly 90% less than fresh ones, so every follow-up turn on the same project is materially cheaper.
2. A fresh sandbox is created. A per-request in-memory filesystem is spun up. Nothing is shared with other users' projects.
3. The agent plans the schema. It calls db_migration_new for each table: workouts, exercises, workout_exercises. Each migration ships with enable row level security and at least one policy — the linter refuses anything less.
4. mobile/src/db/types.ts is regenerated. Now the mobile code can reference these tables with real column types.
5. The agent calls db_seed. A demo user (that fixed UUID) owns a few workouts. RLS is checked against that user so the seed rows are visible when the preview renders.
6. The agent writes screens. app/(app)/index.tsx, app/(app)/history.tsx, app/(app)/workout/[id].tsx. Each one imports useApp(), grabs the Supabase client, and queries the tables it just created.
7. The preview renders. The Expo runtime bundles the mobile code, connects to the sandbox database, and displays the app.

The whole flow streams via Server-Sent Events. You see tool calls happening in real time: the migration being written, the seed being applied, screens being generated. You can stop mid-flight and steer the next turn.

For a longer walkthrough of the AI pipeline that fronts this, see our post on how RapidNative's two-step AI pipeline generates React Native code.

Why the tool layer matters more than the model

There's a temptation to think the differentiator is the LLM. It isn't. Every serious AI mobile app builder uses a big model — the frontier ones from Anthropic, OpenAI, DeepSeek, Google — and the model choice moves in months, not years.

What sticks is the tool layer. A model with db_migration_new that validates against pg-mem cannot write a broken schema. A model with a linter that requires RLS policies cannot ship a table that returns zero rows in prod. A model whose types are regenerated on every schema change cannot query a dead column.

The same underlying model, running against a tool layer without those gates, will produce demos that look great and fail the second real usage lands. This is the actual difference between an AI fullstack app builder and a screenshot generator.

What this looks like for common app types

Fitness / habit tracker — one users table (from auth.users), a workouts table with owner_id uuid references auth.users(id), RLS policies scoped to auth.uid(). Seed data with the demo user's workouts. Frontend: list, detail, history charts. Add a personal_record table when the user asks for PR tracking.

E-commerce / marketplace — products with using (true) SELECT policy (public catalogue), carts and cart_items scoped to owner_id, orders scoped to owner_id. RLS makes the anonymous-key-in-the-app safe: a compromised client can read products but not other people's carts.

Social feed — posts with public SELECT, likes scoped to owner_id, follows with a self-join policy. When someone asks "add DMs", the agent creates a messages table with a policy that only lets the sender and recipient read the row. RLS doesn't leak.

Booking / scheduling — businesses public, bookings scoped to owner_id, with the business owner also able to see bookings for their business (a slightly more complex policy). The linter still catches it if any policy is missing.

Every one of these apps historically required either (a) days of hand-writing SQL and policies, or (b) using an AI builder that never wrote real backend code, so you had to add it yourself later. The point of the fullstack template is to collapse both into a single prompt whose output you can actually deploy.

FAQ

Does the generated app include real authentication?

Yes. Sign-up, sign-in, and session handling are wired through Supabase Auth. The migration references auth.users(id) for owner columns, and auth.uid() inside RLS policies. It's real auth, not a UI illusion, from the first prompt.

Can I edit the generated SQL migrations?

Yes — they're plain SQL files in supabase/migrations/. You can open them, edit them, and re-run validation. You can also add new migrations by hand and RapidNative will keep them in the same ordering.

Does this work offline once downloaded?

Yes. The generated project is a standard Expo + Supabase project. You can supabase start to run Postgres locally in Docker, npx expo start to run the app, and iterate offline against the local database.

How is this different from RapidNative's earlier fullstack template?

The earlier fullstack-v2 template held schema in JSON records and generated a TypeScript layer on top. The new fullstack-supabase template uses SQL migrations as the source of truth, validates them against an in-memory Postgres, and enforces RLS at the tool layer. Real Supabase, no abstraction.

What if the AI writes a broken migration?

It never lands on disk. The migration is applied in-memory first; if it fails, the tool returns an error and the agent tries again. You never end up in a half-applied state.

Can I deploy the generated app to production?

Yes. The supabase/ directory is exactly the layout the Supabase CLI expects, so supabase db push deploys the schema to your project. The mobile/ directory is a standard Expo app that goes through EAS Build to the App Store and Google Play.

Try it

Start with a prompt. Something as simple as "Build a workout tracker with a history log" generates a database, RLS policies, seed data, and screens — in a single turn. If it doesn't quite fit the shape of your idea, ask for a change. The next turn adds a table, extends a policy, or generates a screen, still going through the same validation gates.

Start building your fullstack app — 20 free credits, no card required. For teams shipping multiple projects, see our pricing page. And if you want the visual walkthrough of the frontend side of the pipeline, we cover it in How RapidNative Delivers Real-Time React Native Live Preview.

The right way to evaluate an AI fullstack app builder isn't whether the preview screen looks pretty on the landing page. It's whether the migration files it produced would be accepted by a code review. That's the bar the fullstack template is built to clear.