Build a working app from a plain-English spec (Lovable / Replit Agent / v0)

The task

You don't need an engineer to get a working version of your idea anymore — you need a clear one-page spec and an AI builder that turns it into a real, clickable app. This guide takes you from a plain-English description to a deployed prototype with screens, a database, and working interactions, using Lovable (Replit Agent and v0 work the same way). It's for founders, operators, consultants, and PMs who want to test an idea this week instead of waiting on a dev queue.

The catch worth knowing up front: these tools are excellent for internal tools and MVPs, and genuinely risky for anything touching payments, logins, or customer data without a real engineer's review — so we build and draw that line clearly. Skip this if the app handles real payments, medical/financial data, or production logins from day one — those need an engineer, not a vibe-coded prototype.

Before AI

Getting a clickable prototype meant either learning to code, hiring a contractor (days to weeks, hundreds to thousands of dollars), or faking it in slides. Our worked example — a client-intake + project tracker — was a spreadsheet you kept forgetting to update. After: a shareable app you built in an hour. Swap in your own idea; the method is identical.

What you'll need

• Lovable (free tier builds and previews; ~$25/mo removes message limits and unlocks publishing). Alternatives: Replit Agent, v0.dev, Bolt.new.
• A plain-English idea for a small, single-purpose app. (Big multi-feature apps fail here — keep it to one job.)
• Optional: a free Supabase account for the database (Lovable sets this up in-flow).
• Skill level: no code. You'll read what it builds, not write it.

The workflow

1. Write the one-page spec first. This is the whole game. The quality of the app is set by the quality of the spec, not prompt-wizardry. Fill in this template before you touch Lovable:

APP NAME: Client Tracker
WHAT IT DOES (one sentence): Capture new clients and track each project's status.
WHO USES IT: Just me (solo), no logins needed for v1.
SCREENS:
  1. Intake form — add a new client (name, email, company, project type, budget)
  2. Projects table — list all clients with status, sortable, filterable by status
  3. Dashboard — count of projects by status (Lead / Active / Done)
DATA I'm storing: clients (name, email, company, project_type, budget, status, created_date)
KEY RULE: status is one of: Lead, Active, Done. New clients default to "Lead".
NOT in v1: payments, emails, user accounts, file uploads.

The "NOT in v1" line is the most important — it stops the AI from over-building and breaking.

2. Start the build. Open Lovable → New Project, and paste:

Build the app described below. Start with just the screens and a clean, simple
UI — we'll wire up the database after. Use clear navigation between the three
screens. Don't add features I didn't ask for.

[paste your spec from Step 1]

Within a minute you get a live preview with three navigable screens. If it added login screens or extra pages, reply "remove anything not in my spec."

3. Lock the data model explicitly. Don't let it guess your fields:

Set up the database for this. Create one table "clients" with these fields:
name (text), email (text), company (text), project_type (text),
budget (number), status (text, one of Lead/Active/Done, default Lead),
created_date (auto timestamp). Connect the intake form to insert rows,
and the projects table to read from it.

When it asks to connect Supabase, say yes — that's what makes your data persist.

4. Iterate one change at a time. The #1 mistake is asking for five changes in one prompt; it'll half-do all of them. One prompt, one change:

On the Projects table, add a filter dropdown at the top to show only one
status at a time. Keep everything else exactly as it is.

The phrase "keep everything else exactly as it is" prevents it from silently rewriting a screen that already worked.

5. Wire the dashboard counts.

On the Dashboard, show three number cards: count of clients with status
Lead, Active, and Done. Pull live from the clients table.

6. Test it like a user. Add 3–4 real clients through the intake form. Confirm they appear in the table, the filter works, and the dashboard counts move. If it survives real data entry, the core works.

7. Publish (read Data & security first). Click Publish for a shareable URL. For a solo internal tool with no logins and no sensitive data, this is fine to share with your team.

Verify it worked

• All three screens load and navigate cleanly.
• A client added in the form persists after a page refresh (proves the database is real, not fake placeholder state).
• The status filter and dashboard counts respond to real data.
• It contains only what your spec asked for — no surprise login/payment screens.

Troubleshooting

• It built too much and now it's broken. Start fresh with the "Don't add features I didn't ask for" + "NOT in v1" lines — scope is the fix.
• My data disappears on refresh. You're on fake in-memory state; re-run Step 3 and accept the Supabase connection.
• It broke a screen that was working. Use Lovable's version history to roll back, then re-prompt with "keep everything else exactly as it is."
• It keeps adding logins. Reply "this is a solo internal tool, no authentication in v1."

Reality check

What's verified: these tools are real and at scale — Lovable reported ~$200M ARR at a $6.6B valuation (Dec 2025), Replit raised at $9B (Mar 2026), and a YC cohort reportedly had ~25% of startups with 95% of their code AI-written. What's not verified is any "build a startup in a weekend" productivity multiplier — the "95% AI-written" figure measures code authorship, not correctness or maintainability. Vibe-coded apps routinely ship with security holes and no tests, and get fragile as complexity grows. Perfect for internal tools, prototypes, and MVPs you'll later rebuild; not a substitute for engineering on anything with real auth, payments, or sensitive data.

Data & security

The moment your app stores real customer data, you own that data's security — and a vibe-coded prototype has not been security-reviewed. Before putting any personal, customer, payment, or regulated data into a published app: have an engineer review the database access rules (these tools frequently leave data readable by anyone with the URL), add real authentication, and confirm where the data lives. For a solo, no-PII internal tool, you're fine.

Going further

• Own the code: export the project to GitHub so you're not locked in and an engineer can take it further.
• Graduate the prototype: once it proves the idea, scope a proper build — the spec from Step 1 is your handoff doc.
• Pair with: the AI Pain Radar guide (validate the idea first) and the custom-CRM guide (same method).

Your takeaway

Download the one-page App Spec template (Step 1) + the 6-prompt build pack (Steps 2–5). Fill the spec, paste the prompts in order, and you have a working app in an hour. The spec does the heavy lifting, you change one thing per prompt, and you stop at "prototype" until an engineer clears it for real data.