How to Write a Prompt Spec for Lovable or Cursor (Free Template)

What a prompt spec is (and what it is not)

A prompt spec is your single source of truth for the build. You paste it into the AI tool as your first message, and you send the same document to the studio. The idea is simple. AI tools fill every gap with a guess. A spec removes the gaps, so you get fewer guesses in the code and fewer open questions when you talk to developers. It is not:

• A pitch deck. No market size, no vision slides.
• A full PRD. No 30-page document. One to three pages is enough for a v1.
• A list of prompts. Prompts change every hour. The spec changes only when your decision changes.

How a spec helps you fit a fixed-price v1

Our MVP is Fixed at $3,460, and we agree the quote before we write any code. That price covers a v1. The spec is how you decide what your v1 actually is: one core job, the screens it needs, the data it stores, and what waits until later. A good spec also shows extra scope early: a second user type, payouts between users, an admin panel nobody asked for. You can decide to keep each one or move it to a "Later" list before the call. Then the free 30-minute call goes on your product, not on basic questions. You can see what the package includes on our MVP Development page.

The 10-part prompt spec template

Copy this structure into a doc. Keep each answer short and concrete. For each section, you'll see what to write and why it matters for v1.

• 1. One-line product. What to write: "[App] helps [user] do [job] without [pain]." Why it matters for v1: it forces one core job. Two jobs means two products.
• 2. Users and roles. What to write: every user type, and what each one can do. Why it matters for v1: each extra role adds screens, permissions and tests.
• 3. Core loop. What to write: the 3 to 7 steps a user repeats, in order. Why it matters for v1: this is what gets built first and best.
• 4. Screens. What to write: a numbered list with one line per screen. Why it matters for v1: the clearest way to see the size of your v1.
• 5. Data. What to write: each object and its fields (User: name, email, plan). Why it matters for v1: it defines the database. Vague data means rework later.
• 6. Rules. What to write: who can see, edit or delete what. Why it matters for v1: security work. Missing rules are the classic AI draft gap.
• 7. Money. What to write: free, one-off payment, or subscription, and which platform. Why it matters for v1: Stripe on web, in-app purchase on iOS and Android.
• 8. Integrations. What to write: every outside service, like maps, email, calendar or an AI API. Why it matters for v1: each one is a dependency to set up and test.
• 9. Platforms. What to write: web, iOS, Android, or all three. Why it matters for v1: it tells the team which stores to prepare for.
• 10. Out of scope for v1. What to write: what you are deliberately not building. Why it matters for v1: this is the section that keeps v1 focused.

A filled example

Here is how a short spec could read for a booking app for independent personal trainers. Look at section 10. "Trainer discovery" would turn this into a marketplace. Leaving it out keeps one paying user type and no payouts between strangers.

• 1. One-line product: "FitSlot helps personal trainers fill their week without chasing clients on WhatsApp."
• 2. Users and roles: Trainer (sets availability, sees bookings). Client (books and pays). No admin role in v1.
• 3. Core loop: Trainer shares a link. Client picks a slot. Client pays. Both get a confirmation. Trainer sees the day's schedule.
• 4. Screens: Sign up, trainer availability, public booking page, checkout, confirmation, trainer schedule, client bookings, settings.
• 5. Data: Trainer (name, email, rate, timezone). Slot (start, end, status). Booking (client, slot, paid, amount).
• 6. Rules: Clients see only their own bookings. Trainers see only their own clients.
• 7. Money: One-off payment per session through Stripe. No subscriptions in v1.
• 8. Integrations: Stripe, transactional email.
• 9. Platforms: Web, iOS and Android.
• 10. Out of scope: Group classes, packages, reviews, trainer discovery, chat.

How to use the spec in Lovable or Cursor

The spec only works if the tool reads it before it writes anything. Halfway there and not sure your draft can go to production? Book a call and we'll go through your spec and prototype with you.

• 1. Paste it as your first message. In Lovable, you can also save it in the project's knowledge settings. In Cursor, keep it as a file in the repo (or in your project rules) so the agent can refer to it.
• 2. Ask the AI to restate the plan. Tell it: "Before writing code, list the screens, data and rules you understood, plus every assumption you're making." Every wrong assumption points to a gap in your spec. Fix the spec, not just the chat.
• 3. Build in the order of section 4. One screen at a time. Test it before moving on.
• 4. Change the spec first, then prompt. If you add a feature mid-build, write it into the spec. Otherwise the spec and the app drift apart, and the studio reads a document that no longer matches what you built.
• 5. Mark what is fake. AI drafts often fake data, skip login checks or hard-code payments. Add a line under each section: "Working", "Mocked" or "Not built".

What to send the studio

A clean handover lets a studio scope your v1 from facts. With this pack, the studio can tell you what fits. Our AI prototype to production page starts from one question: "Can this go live, and what exactly is still a prototype?" If you're wondering when to stop prompting and bring in developers, browse our Lovable and AI builder guides. Send:

• The spec, up to date, with the "Working / Mocked / Not built" notes.
• The prototype link, so they can click through the real flow.
• The code, if you have it. Lovable can sync to GitHub, and a Cursor project already lives in a repo.
• Your launch deadline and the reason for it (investor meeting, pilot customer, event).
• Your must-have list: the three things v1 can't launch without.

Common spec mistakes that blow up a v1

Watch for these when you reread your spec. To see which features usually take the most build work, read our feature cost guides.

• "Like Uber, but for X." That isn't a spec. Write the steps your user takes instead.
• "Admin dashboard" with no details. Say exactly which three things you need to see or do. Often a spreadsheet or the database console is enough for v1.
• "AI-powered" with no task. Name the input, the output and what happens when the AI is wrong.
• No out-of-scope list. Without it, every idea you mentioned in passing ends up in the build.
• Mixing v1 and v3. Put later ideas in a "Later" list at the bottom. They stay on record and stay out of v1.

Turn your spec into a real app

Ready to turn your spec into a real app on web, iOS and Android? Fixed at $3,460, delivered in about 20 days. You see progress every week, design is included, and the code is 100% yours on your GitHub. Book a call.

What is a prompt spec?

A prompt spec is a short document that describes your app's users, core loop, screens, data, rules and scope in plain English. You paste it into an AI builder like Lovable or Cursor before generating code. You also share it with a studio so they can scope your build.

How long should a prompt spec be for an MVP?

One to three pages is usually enough. If yours is longer, you are probably describing more than one product, or features that belong after launch.

Do I need a working prototype before hiring a studio?

No. A clear spec is enough to start. A prototype helps because the studio can click through your flow, but you don't need one.

Does a spec change the price?

No. Our price is Fixed at $3,460, and you get the fixed quote before any work starts. The spec helps you decide what goes into v1 and what waits. It also lets us use the call for your product instead of basic questions.