How to vibe code: a beginner workflow that actually ships

Most "how to vibe code" tutorials show you the fun bit — prompt goes in, beautiful interface comes out — and skip everything that turns a demo into something real users can actually rely on.

This is the shape of the workflow I follow on every Lovable app I ship to paying clients. Not the prompts (those live in the Field Guide), but the order, which is honestly the bit most beginners get wrong.

Phase 1 — Scope before you type

The single biggest predictor of whether a vibe-coded app ends up usable is whether you scoped it properly before opening the builder. Not "had a vague idea". Scoped it.

That means deciding, on paper or in a doc:

• Who the user actually is and what one specific job they're hiring this app to do.
• What "done" looks like for v1. (Hint: it's smaller than you think.)
• What you are deliberately not building.

I run this through an AI conversation before I touch Lovable — basically using the AI as a product manager to interrogate the idea. The full PID-style prompt that produces a paste-ready brief is in Chapter 2 of the Field Guide, but you can get a long way with "interview me like a sceptical PM and only stop when you understand exactly what I'm building and for whom."

Phase 2 — Architecture, before the first feature

This is the phase that separates apps that survive their tenth feature from apps that collapse under their own weight at month two.

Before you build a single screen, you need to have answered:

• What are the main entities in your data model? (Users, organisations, jobs, invoices, whatever.)
• How do they relate?
• What are the obvious "shared" pieces of UI — the bits that need to look and behave consistently across the app?

Vibe coding tools are weirdly good at building features and weirdly bad at refactoring chaos. Decide architecture once, up front, and it costs you almost nothing. Try to retrofit it after twenty screens and you'll feel it.

Phase 3 — Build the core loop, nothing else

Pick the one flow that proves your app does the thing. For a maintenance app, that's: cleaner reports issue → manager sees it → contractor fixes it. Three steps. Build that and only that.

Resist every urge to add settings pages, profile editors, dashboards, dark mode, AI features, anything. Those are phase 5.

Phase 4 — Make it not embarrassing on a phone

Over half your traffic will be mobile. Open the app on a real phone — not the browser simulator — and use it. If you can't comfortably tap the buttons or read the text, the app doesn't work, regardless of what the desktop view looks like.

There's a specific prompt I use to make Lovable do this properly in one pass. It's in Chapter 4 of the Field Guide. Without that prompt, you'll spend half a day fighting it.

Phase 5 — Harden before you let humans in

This is where most beginner vibe-coded apps quietly fall apart. The interface is finished, the core flow works, and the assumption is "done". It isn't. You haven't yet:

• Locked down who can see and edit which rows of data.
• Decided what happens when something goes wrong (errors, empty states, slow connections).
• Tested the payment flow with a real card.
• Set up a real domain and real email.
• Run the app through any kind of pre-launch check.

Each of those is a small thing that, missed, will bite you in front of a real customer. The pre-launch checklist I run on every app — the actual line-by-line one — is Appendix B of the Field Guide.

Phase 6 — Ship, then iterate

This is the easy bit and the bit beginners overthink. Once the core works and the basics are locked down: ship it. To one real user if you have to. Watch what they actually do. Then iterate.

The trap is polishing for another two weeks because it's not "ready". It's never going to feel ready. The only thing that makes an app better is real users using it.

---

That's the shape. The Field Guide is where the actual prompts live — the PID-generator prompt, the architecture-setup prompt, the mobile-responsiveness prompt, the debugging method I use when Lovable goes sideways, and Appendix A which is just a copy-paste library of the prompts I use across every project.