--- slug: good-lovable-app-spec title: "What a Good Spec for Lovable Looks Like" excerpt: "Lovable's intake is short on purpose, so what you don't say becomes whatever it thinks you meant. A six-field Lovable app spec fills in the gaps." primaryKeyword: "Lovable app spec" publishedAt: 2026-04-15 readingTimeMin: 6 author: "Robert Boylan" tags: - lovable - lovable-app-spec - ai-app-builder - indie-founder - app-planning --- You've got fifteen minutes, a laptop, and an app idea you're oddly proud of. You open Lovable, type "a nutrition tracker for people who meal-prep on Sundays," and hit generate. Lovable builds something. It's fast. It looks nice. It's also not really the app you had in your head. Somewhere between "the idea" and "the thing that appeared on screen," a lot of your intent got lost. Not because Lovable isn't smart. Because Lovable's intake is deliberately light. This post is about what to write into Lovable before it starts building, so the thing it produces looks more like the thing you actually wanted. Call it a **Lovable app spec**: a short, structured brief that fills in the context Lovable won't ask for on its own. Quick context if you're new to any of this. Lovable is a visual AI app builder for people who don't want to touch code. You describe the app in plain language, it generates a working web app in the browser, and you keep describing changes until it matches what you want. It sits somewhere between Figma and Webflow, with a side of Cursor. Indie founders, designers, and non-coders use it to ship real products in days. ## Why Lovable's intake leaves gaps on purpose Think about who Lovable is built for. A first-time founder. A designer testing an idea on a Saturday. Someone who has used Figma and Notion but has never touched a terminal. For that user, the worst possible intake screen is one that asks ten questions up front. It would feel like paperwork before you get to play. So Lovable keeps the intake light. One prompt. Hit generate. Iterate from there. Same goes for most tools in this category (v0, Bolt.new, Figma Make). They're all built to get you _inside_ the builder as fast as possible, because that's where the magic happens. The trade-off is that Lovable fills in the gaps with reasonable defaults. Modern styling. A handful of features. A signup button, because apps usually have one. If any of those defaults aren't what you wanted, you find out around prompt four, when you're asking it to redo the navigation for the third time and wondering where the calorie-tracking feature came from. A pre-written Lovable app spec fills those gaps before Lovable does. You paste it in on the first turn, and the first generation already lands closer to what you pictured. ## The six things a good Lovable app spec covers A Lovable app spec isn't a 20-page PRD (a product requirements document, basically the full plan a product manager hands an engineer). It's a page, sometimes less, with six fields. Each one answers a question Lovable won't ask. 1. **One-sentence description.** What the app is. "A private meal-prep tracker for people who plan their week on Sundays." If you can't say it in a sentence, Lovable can't build it in ten prompts. 2. **Top three features, in order.** Not five, not ten. Three. Ranked. The first one becomes the main screen Lovable builds around. The order matters because everything else hangs off it. 3. **The user.** Even if the user is just you. "Solo user, desktop, logged-in" is a different app than "anyone who signs up, mostly on phones." Lovable will pick one of those by default. You want to be the one picking. 4. **What you're _not_ building.** This is the single most valuable line in the spec. "Not building: social features, multi-user, payments, mobile app." It blocks a class of drift Lovable would otherwise introduce on prompt five. Lovable's defaults skew maximalist; your non-goals pull them back. 5. **Design mood.** Three or four words. "Warm, editorial, not startup-y." "Playful, high-contrast, feels like a game." Lovable is very good at visual direction when you give it any. It reverts to "modern SaaS" when you don't. 6. **Anything you feel strongly about.** Constraints and opinions that override the defaults. "No signup, the app just works." "Local storage only." "Must work offline." "Light mode, always." One short line each. Six fields, ten minutes. The whole thing fits on a card. ## How to describe the look without being a designer The design mood line trips people up. Most non-designers freeze when asked to describe an aesthetic because "minimal" feels boring and "modern" feels meaningless. Two tricks that work well with Lovable: - **Name a reference.** "Feels like Linear." "Looks like a calm Notion page." "Warm and paper-y, like Read.cv." "Has the energy of a Tumblr circa 2012." Lovable recognises enough app-world references to pick up the vibe, and that's much faster than trying to list colors. - **Pair an emotion with a constraint.** "Calm and clear, no gradients." "Playful, not childish." "Confident and loud, lots of color." Lovable handles emotional adjectives far better than hex codes. Writing "modern and clean" tells Lovable nothing. Writing "warm, editorial, like a food magazine, not a SaaS dashboard" tells it everything. The difference is roughly zero extra effort and about half your later prompts. ## A worked example: the same idea, sloppy vs structured Here's what the difference looks like in practice. **The sloppy version:** "Build me a nutrition tracker." Lovable generates something. Probably a dashboard. Probably with a signup screen. Probably with a "Today's calories" card up top, because that's what most nutrition trackers do. None of that is wrong. It's also not what you wanted, which was a lightweight thing to help plan Sunday meal prep. **The structured version:** "A private meal-prep tracker for one user (me, on desktop). Three features, in order: (1) plan the week's lunches on a simple Sunday-to-Saturday grid, (2) save favourite recipes and drag them onto the grid, (3) generate a shopping list automatically when the week is planned. Not building: social sharing, macro tracking, signup, mobile app, dark mode. Design mood: warm, editorial, like a recipe book, not a SaaS dashboard. Strong opinions: no login, local storage only, everything fits on one screen." Same idea. Forty seconds longer to write. The first generation Lovable produces now actually looks like the thing you had in your head, because there's no room left for it to hallucinate "calorie tracking" into existence. This is the gap [a good spec (and Draftlytic specifically) is built to close](/what-is-a-prd): it walks you through the six fields, then hands you a paste-ready brief. ## Keeping the spec in front of Lovable as you build Writing the spec is half the job. Using it throughout the session is the other half. Three ways to keep it working for you: - **Paste the whole spec into the first prompt.** Don't type a one-sentence version, hit send, and paste the spec later. Lovable weighs the first turn heavily. Lead with the full brief. - **Re-paste it when you start a new chat.** Lovable's memory across sessions is patchy. The spec is cheap. Paste it whenever the context resets. - **Refer back to it when things drift.** When Lovable adds a feature you didn't ask for, the fix isn't "stop adding social features." The fix is "per the spec, not building social features. Remove." Pointing at the spec is clearer than re-describing the problem. The spec becomes the source of truth you and Lovable can both point at. The chat becomes scratch work. This is the same anchor pattern that prevents [AI code drift in any longer session](/blog/why-ai-code-gets-worse-over-time), applied to Lovable's specific shape and audience. ## The takeaway Lovable is genuinely good at building apps from clear briefs, and pretty bad at reading minds. Its intake is short on purpose, which means the thing you don't say becomes whatever Lovable thinks you probably meant. Most of the friction people feel with it isn't a Lovable problem. It's a brief problem. The fix is a one-page Lovable app spec: the six fields covered above, written before you hit generate. Writing the spec isn't the hard part. Remembering which six fields matter, in the right order, for an idea you haven't built yet is. That's the gap Draftlytic is built around. You describe the idea, it walks you through the thinking, and hands you a spec that pastes straight into Lovable. The first generation already looks like the thing in your head.