Building Apps in Lovable: The Vye Playbook

Start here: the one rule

Think in Claude. Build in Lovable.

Lovable charges by the message, and complexity drives the price. Every minute you spend "figuring out what you want" inside Lovable costs credits. So we do all of that thinking in Claude first — for free — and hand Lovable a precise, finished spec. Lovable is the most expensive place to brainstorm; never do it there.

This article is the distilled version of everything we've learned shipping real Lovable builds at Vye — lead-gen quizzes, client assessments, the proposal-tool concept, microsites. Follow it and you'll spend a fraction of the credits and get better results. There's also a Claude skill, Vye Lovable Spec Writer, that walks you through writing the spec; this article is the human-readable companion.

The Vye build workflow

Five steps, in order. Most credit waste comes from skipping straight to step 3.

Step 1 — Spec it in Claude first. Before you open Lovable, write the spec with Claude. Trigger the Vye Lovable Spec Writer skill and answer its questions. The output is a single paste-ready spec covering every screen, every line of copy, the brand standards, the data model, and the open questions. This is where the project actually gets designed.

Step 2 — Use Plan mode before Build mode. Paste the spec into Lovable, but use Plan/Chat mode first. Ask Lovable to restate what it's going to build and confirm it matches your spec. Read it. If it misunderstood something, fix it in the conversation — that's free. Only then switch to Build. This one habit prevents the most expensive mistake in Lovable: building the wrong thing and paying to redo it.

Step 3 — Build. Let Lovable build from the agreed plan. Because the spec was detailed and the plan was confirmed, the first build lands close. Expect roughly 80% done on the first pass.

Step 4 — QA every pass. Open the result and actually use it. Click everything. We've been burned by counters that don't sum, scores that read backwards, edge-case copy that contradicts the result (a "perfect score" screen still warning you about risks), and CTA buttons that looked right but weren't routing through HubSpot tracking. QA against the spec's acceptance criteria and write down what's wrong.

Step 5 — Iterate with update prompts, never rebuild. Turn your QA notes into a tight, numbered update prompt that changes only what needs changing and explicitly tells Lovable to iterate on the current build, not rebuild. State that approved copy and working pieces stay untouched. Order the changes by impact. Rebuilding from scratch to fix three things is the fastest way to burn credits — surgical update prompts are the cheap, professional way to iterate.

Writing a spec that actually works

Detail and accuracy are the whole game. The spec should be specific enough that two different builders would produce the same app. Include:

• Goal + the single success metric. What is this measured on — demo volume, total leads, signed proposals? Scope to that one thing and don't gold-plate a thin idea.
• Every screen, in order, with layout, every element, and every state — including the empty/zero state and error states.
• All copy, verbatim. If approved copy exists (HubSpot, a copy doc), use it word-for-word and keep it stable so downstream systems don't break.
• Exact logic. Spell out numbers, counts ("N of 6 selected"), how things sum, and which direction is "good" on any score. Ambiguity here is our #1 source of bugs.
• Brand standards. See the next section.
• Data model, if anything is stored: every field, its type, and where it's written.
• Acceptance criteria + open questions/blockers at the end, separating true launch blockers from nice-to-haves.

Getting brand standards into Lovable

Client-facing tools must be on-brand from the first build, not corrected later. Don't let Lovable invent colors or substitute a lookalike font. Feed it the real standards, pulled from the client's brand guide:

• Exact hex codes for primary/secondary/accent, and where each is used.
• Fonts. Name the families and weights. If they're custom/licensed, upload the font files into Lovable (or supply a webfont link) — don't let it guess a substitute.
• Logo & wordmark. Upload the real files; specify which variant (full color / reversed / mark) and placement/clear space.
• Imagery. List needed illustrations, icons, and an OG share image (1200×630). Emoji/placeholder stand-ins are fine as a temporary build aid — flag them to swap before launch.
• Voice/tone for any copy the tool generates.

On a Business workspace, build a reusable Vye-branded design template once so future builds start on-brand and spend fewer credits getting there.

Vye account vs. the client's own account

Decide this before you build, and put it in the spec. Getting it wrong means migrating a project later or carrying a client's credit burn on our bill.

Rule of thumb: when a build starts turning into the client's long-term product, that's the prompt to have them stand up their own account before the project grows further. Don't let a "quick campaign tool" quietly become a product we're hosting and funding indefinitely.

Lovable vs. Claude: pick the right tool

Not everything belongs in Lovable. Using the wrong tool either wastes credits or produces a worse result.

The money-saving move: if the logic is uncertain, prototype it as a Claude artifact first. Proving a concept in an artifact costs nothing; proving it in Lovable costs credits on every iteration. Once the concept is right, write the spec and build it for real in Lovable.

Building reporting & admin dashboards

Dashboards are a common ask, and Lovable can do them well — but only some of them belong there.

Build it in Lovable when it's a persistent, multi-user dashboard people log into over time — a client-facing portal, an internal admin panel, a tool with saved state and roles. In that case: define the data schema first, use Supabase for the database and auth, set up roles/permissions, and specify every single metric and chart explicitly (name, source, calculation, format). Provide sample data so Lovable can build and you can QA against known numbers.

Don't build it in Lovable when it's really a live report pulling from our connected tools (HubSpot, GA4, Ahrefs, BrightLocal). For those, a Claude/Cowork artifact that reads live connector data is faster to stand up, costs no Lovable credits, and refreshes on open. Reach for Lovable only when you genuinely need persistence, logins, or a standalone product the client owns.

The Vye stack cheat sheet

Defaults that have worked for us, so you're not researching the same integrations every time:

A note on collecting sensitive data: never store raw credit-card numbers in a plain form/database — that's a PCI compliance problem. Capture only safe billing-contact info (name, email, address, PO, terms) and let accounting invoice through our existing system, or use Stripe if you actually need to process a payment.

Pitfalls we've already hit

Learn these for free instead of rediscovering them on the clock:

• Brainstorming inside Lovable. The single most expensive habit. Spec in Claude first, every time.
• Rebuilding to fix small things. Use surgical update prompts that iterate on the existing build.
• Vague logic. "Show their score" isn't enough — say how it sums and which direction is good, or you'll get counters stuck at 0 and backwards scores.
• Edge-case copy. Make result copy tier-aware. A perfect score shouldn't still warn the user about risks they don't have.
• Gating shallow value. Don't bury an already-visible result behind a redundant form. Either deepen the value or make the form a plain CTA.
• Assuming tracking "looks" right. Branded buttons aren't HubSpot embeds. Verify a click actually routes through HubSpot before launch.
• Expecting 100% on pass one. Lovable gets ~80% fast; budget focused prompting (or a little dev time) for the last mile — exports, edge cases, polish.

Pre-launch checklist

Before any client-facing Lovable tool goes live:

• Brand correct — real hex codes, fonts, logos in place; placeholders swapped
• All copy matches the approved source word-for-word
• Every interaction, counter, and score verified in QA, including edge cases
• CTAs link correctly and tracking routes through HubSpot
• Mobile layout checked, not just desktop
• Custom domain / CNAME live and any cookie-consent / legal disclosures in place
• Download/print/share actions present if the spec called for them
• Account ownership confirmed (Vye vs. client) and client projects restricted to their team

TL;DR

Spec in Claude. Plan before build. Build. QA. Update — never rebuild. Keep it on-brand from the first pass, decide whose account it lives in up front, use Lovable only for things that genuinely need to be apps, and verify everything before you hand a client a link.