From a Lovable mockup to a sealed plan

AI prototyping tools — Lovable, v0, Base44, Bolt — are some of the most powerful artefacts our industry has produced in the last two years. They compress what used to take a designer plus a frontend engineer plus a week into about forty-five minutes of conversation. And then we throw them away.

The mockup gets shown in a meeting. Someone says “great, let's build it.” Someone else volunteers to translate the mockup into Jira tickets. The translation takes two days, loses about a third of the design intent, and ships into a sprint where the engineers will reverse-engineer the original screenshot anyway. The mockup is a Polaroid. It should have been a contract.

The mockup is evidence

We treat mockups the way an architect treats a site survey: as primary source material that the spec must reference. SpecGraph reads the mockup — pasted URL, screenshot, or exported HTML — extracts design tokens (primary, surface, type, radius, density), infers the surfaces (sign-in, dashboard, settings, empty state), and seeds the brief with what it knows. What it doesn'tknow becomes the first six questions of the voice interview.

The result is a brief that already knows what your product looks like. The voice interview then asks what your product is for — and the two artefacts converge into a single sealed plan.

Prototype the feel on Lovable. Ship the plan from SpecGraph. The mockup becomes evidence inside the spec — not a throwaway.

A typical workflow

It looks like this in practice. We're using a recent healthtech engagement as the example; the proper nouns are anonymised but the steps are real.

• Day 1. Founder spends ninety minutes on Lovable producing a coherent mockup of a patient-intake flow. It's rough but the shape is right.
• Day 2. The Lovable URL is dropped into SpecGraph. Tokens extracted. Eleven surfaces detected. Six prompts seeded for the interview.
• Day 3. Voice interview runs. Twenty-five minutes. Vision, audience, constraints filled in. The brief is now half a page longer than the mockup justified — that's a feature, not a bug.
• Day 4–6. Wishes flow in from product, engineering, compliance, finance, ops. Two conflicts surface. Both resolved by Friday.
• Day 7. Spec sealed at v1.0.0. BMAD pack served over MCP. Claude Code reads it. First two stories on the board the same evening.

Why this works

Because the mockup answers the question every PRD struggles with: “what does this thing actually look like?”. The spec answers a different question: “why does this thing exist, and what is it not allowed to be?”. Each artefact does what the other can't. Together they're a contract a coding agent can execute verbatim.

What you can do this week

• Take the next feature you're about to scope. Spend an afternoon on Lovable or v0 producing a mockup. Then write the brief in response to the mockup, not from scratch.
• Save the mockup URL inside the brief. Reference it. Make it part of the artefact, not a thing the engineers Slack each other later.
• When the spec is sealed, give the agent the pack and the mockup link. The pack tells it what to do. The mockup tells it what “done” looks like.

Mockups are too good to throw away. Specs are too important to leave fuzzy. The two need to live in the same artefact.