How I Ship AI Apps: My Lovable → Claude Code → Supabase Pipeline
People ask how a one-person shop ships working AI products alongside consulting work. The honest answer is a pipeline with three stages and very clear rules about what each stage is allowed to do. Here it is, breaks first where they belong, because the breaks are why you can trust the rest.
The stack in one paragraph
Lovable builds the first version of the product: UI, pages, flows, the thing you can click. Claude Code handles everything after that: refactoring, build tooling, real features, anything where I need to see every changed line. Supabase sits underneath the whole time, providing the database, auth, and Edge Functions, which is where the AI itself lives via the Claude API. Deployment stays simple: the repo is the source of truth, and pushes go live.
Each tool is excellent at one phase and mediocre at the others. The pipeline works because I stop using each tool at the point where it stops being the best option, and that discipline matters more than the tool choices themselves.
Stage one: Lovable, for product shape
Where it breaks
Ambitious prompts. Ask Lovable for a visual tweak, get a visual tweak. Ask it for a cross-cutting change like restructuring state or modifying how data flows, and you're gambling. Version history makes the gamble survivable (note your version number before every risky prompt), but past a certain project size I stop gambling entirely and move to stage two.
What it's for anyway
Lovable's superpower is speed to something real. In a day I can have an app with actual screens, actual navigation, and a Supabase backend wired in, which means in a day I can discover that my tile layout is wrong, the flow has a missing step, or the feature I was excited about is actually confusing. Finding that out in day one instead of week four is the entire value.
The rule I hold myself to: Lovable is for shaping the product, not engineering it. I prompt in product language (what a screen shows, what happens when the user does X) and I resist the urge to prompt architectural changes. Lovable will happily attempt them, and that's exactly when it rewrites things you didn't ask it to touch.
Stage two: Claude Code, for engineering
Where it breaks
Context. On a bigger codebase, Claude Code can make a locally sensible change that violates a project-wide convention it didn't have in view. The other failure mode is mine, not the tool's: accepting a diff I skimmed instead of read.
What holds it together
Once the product shape is right, I connect the Lovable project to GitHub and shift my center of gravity to Claude Code. Same repo, different relationship: now every change is a diff I review before it ships. This is where the unglamorous work happens. Cleaning up the generated code (Lovable output is fine but repetitive; components want consolidating), adding things Lovable is weak at (build scripts, static generation, testing, performance passes), and building the features with real logic in them.
Two habits do most of the heavy lifting, and both exist because of the breaks above. First, a maintained CLAUDE.md in every repo listing conventions, architecture decisions, and things Claude Code should never touch. I keep it standardized across projects so every session starts oriented instead of exploring; it's the direct answer to the context problem, and it earns its keep every single session. Second, plan-first prompting: I ask Claude Code to inspect the code and confirm its approach before writing anything. That one habit prevents most of the "technically what I asked for, not what I meant" category of rework.
The layer underneath: Supabase, and where the AI lives
Where it breaks
Timeouts and streaming. Long AI generations bump against Edge Function limits, so anything heavy either streams to the client or gets broken into smaller calls. I learned both versions of that lesson in production.
The pattern that works
Supabase is the constant across both stages. Postgres, auth, row-level security, storage. But the piece worth dwelling on is Edge Functions, because that's where the actual AI runs.
Every AI feature in my products follows the same pattern: the client calls an Edge Function, the Edge Function calls the Claude API, shapes the response, and returns it. The API key lives server-side, never in the browser. The prompt lives server-side too, which matters more than people realize: it means I can improve the AI's behavior, tighten the output format, or handle a new edge case by redeploying one function, without touching the app at all.
Two hard-won details. Force JSON discipline: when a feature needs structured output, the system prompt demands raw JSON with no preamble, and the function still strips markdown fences and parses defensively, because the one time in fifty it wraps the response will otherwise be a production bug. And log the failures: every malformed response gets captured, because those logs are exactly the examples you need to fix the prompt.
What I wouldn't run through this pipeline
Honesty requires a boundary, so here's mine. This pipeline is built for focused business applications: an intake processor, a triage system, a tracker with AI features behind a clean seam. I wouldn't run it for real-time collaborative editing, native mobile, or anything where the data model belongs to a system I don't control and can't cleanly mirror. Those aren't "prompt harder" problems; they're architecture problems, and pretending a fast pipeline solves architecture is how fast pipelines get bad reputations.
Why this works for a small shop
The pattern underneath the pipeline: use the fast tool until precision matters, then switch to the precise tool and don't look back. Lovable gets me a real product in days. Claude Code makes it maintainable. Supabase means I never build auth or infrastructure from scratch. And the AI lives behind one clean seam, the Edge Functions, so it can improve independently of everything else.
None of this requires a team. It requires knowing what each stage is for, and the discipline to move on when you've reached its edge.
If you're building on a similar stack, I compare notes gladly; the contact form on the main site reaches me.