Prompt-to-App Is a Lie — Here's What Actually Happens

You type a sentence. Twenty seconds later there's a "React Native app." That's the pitch every prompt-to-app tool ships with in 2026 — Lovable, Bolt, v0, Replit Agent, and the rest. This post is about what actually happens after the demo screen.

Prompt-to-app tools generate a live-reloading UI in a sandbox against a mocked backend. They do not generate:

• A real auth system with sessions, password reset, and OAuth
• A database you own with migrations and RLS
• Stripe wiring with real webhooks and Apple IAP handling
• An .ipa or .aab you can submit to a store
• The Apple Developer certificate needed to ship

Which is roughly 90% of the actual work.

What the demo shows vs. what production needs

Demo	Production
UI in a web preview	Signed .ipa + .aab submitted to two stores
Mocked API + sample data	Postgres with migrations, backups, RLS
One screen	Deep linking, push, background tasks, offline sync
Preview URL	Real accounts, OAuth, password reset
No integrations	Stripe, IAP, RevenueCat, Sentry, analytics
No secrets	Secret storage, key rotation, review notes

The three walls

Auth. The "Sign In" button works in the preview. It doesn't do anything real. Wiring actual OAuth + sessions + RLS is a rewrite of the data layer.

Payments. On iOS, selling anything digital requires Apple IAP, not Stripe. The tools don't know or care. You'll write this yourself, and it's a two-week job when you factor in webhook handling and license grants.

Submission. No agent creates an Apple Developer certificate. No agent captures screenshots at five device sizes. No agent replies to reviewer feedback. This is 30% of any app.

Why the demo works and the app doesn't

Architecture drift. AI-heavy codebases show 39% higher code churn — code reverted or heavily rewritten within two weeks. LLMs have no persistent memory of the constraints they set twenty prompts ago. They redefine User in three files.

Hidden state. The "backend" is a black-box datastore the tool provisions. You can't run migrations. You can't add a trigger. You can't set up Supabase-style RLS.

Stack lock-in. Most tools are aggressively opinionated. v0 outputs React + Tailwind. If you need Expo, native modules, or actual app store distribution, you're outside the happy path.

No distribution story. Docs for eas submit exist because submission is a real, human-mediated process. No prompt generates it.

The workflow that actually ships

# 1. Start from a template that owns the boring stuff
git clone <template-repo> my-app
cd my-app
bun install

# 2. Point your agent at the repo
# Claude Code, Codex, Cursor, whatever
# Templates ship with .claude/skills/ so the agent knows the conventions

# 3. Extend, don't invent
# "Add a photo upload feature to the events screen"
# "Wire the settings screen to the existing Stripe customer portal"

# 4. Ship
eas build --platform all
eas submit

The agent is in this workflow. It just isn't inventing the architecture.

The split that works

// The template owns things like this:
import { supabase } from "@/lib/supabase";
import { requireAuth } from "@/lib/auth";

export async function uploadNote(userId: string, blob: Blob) {
  await requireAuth(userId);
  return supabase.storage.from("notes").upload(`${userId}/${Date.now()}`, blob);
}

// The agent adds features on top:
export async function shareNoteAsPdf(noteId: string) {
  const note = await getNote(noteId);
  const pdf = await renderPdf(note);
  return uploadNote(note.userId, pdf);
}

The template's supabase, requireAuth, and storage.from("notes") are load-bearing infrastructure. They already work. They already have RLS. The agent's job is the last function, not the first three.

When prompt-to-app is actually fine

• Marketing pages and landing sites (v0 is great for this)
• Prototypes for design review
• One-off internal tools without auth or payments
• Learning what components look like

Prompt-to-app is a rendering technology. It's not a shipping technology. Use it for what it's good at.

FAQ

Q: Are prompt-to-app tools useless?
No. Great for prototypes and marketing pages. Poor fit for shipping real mobile apps.

Q: Won't they get better?
Some of it, over years. Code signing and App Store review aren't things LLMs prompt their way through. Bet on agents inside real projects, not agents inventing them.

Q: What stack should I pick?
Expo, TypeScript, Supabase, NativeWind, Stripe (+ Apple IAP for digital goods). Boring, well-documented, agent-friendly.

---

I keep a set of Expo + Supabase templates wired for exactly this workflow at Applighter.

What's the wall that cost you the most time — auth, payments, or submission? Drop it in the comments.