Your First App in an Afternoon

You can have a working app online by dinner

Here's the whole afternoon in one line: pick a tool (10 minutes), describe your app (15 minutes), let it build (15 minutes), fix what breaks (30 to 60 minutes, this is normal), publish it to a real link (10 minutes), send that link to one person. Roughly 2 to 3 hours, $0 to $25 depending on the tool.

One mindset switch before you start: you are not going to learn to code this afternoon. You're going to learn to direct something that codes. The skill is describing what you want precisely and checking the result, and you already use it every time you brief a contractor or order a custom cake. The prompts on this page are the briefing templates.

Pick a real but small project for today. Good first apps: a tracker for something you actually track (workouts, plants, job applications), a calculator your group chat would use, a signup page for a thing you organize. Bad first apps: "like Airbnb but for X." Three screens or fewer today; the empire next week.

Step 1: pick your tool (and if unsure, it's Lovable)

Four tools matter for a first app: Lovable, Bolt, Replit, and Claude. They're more alike than different, and the full comparison lives in the tool picker file below. The short version:

Our hard opinion: if you're not sure, start with Lovable. It has the least screen to get lost in (a chat on the left, your app on the right), the best-looking default output, and publishing is one button. Every other choice is for a specific reason in the table above. Don't spend 40 minutes researching; the tools are close enough that shipping in any of them beats comparing all of them.

Step 2: your first message decides 80% of the result

The single biggest beginner mistake is typing "build me a workout app" and hoping. The builder will happily invent 12 features you didn't want, and you'll spend the afternoon deleting instead of building. Your first message needs exactly four things: what it is (one sentence), who it's for, which screens (3 or fewer), and what "done" means (checkable, not vibes).

Build me a web app: [ONE SENTENCE: a ___ that lets ___ do ___].

Who it's for: [WHO WILL USE IT, AND WHAT THEY DO TODAY INSTEAD, e.g. "my
climbing group, who currently coordinate sessions in a group chat"]

The screens I need (keep it to 3 or fewer):
1. [SCREEN NAME: its one job, e.g. "Home: shows this week's sessions as cards"]
2. [SCREEN NAME: its one job]
3. [SCREEN NAME: its one job]

"Done" means (checkable, not vibes):
- [e.g. "I can add a session with a date, location, and note"]
- [e.g. "Sessions appear newest first and I can delete one"]

Rules:
- No user accounts, no payments, no features I didn't list. I'll ask later.
- Use placeholder text and sample data where content is missing, and tell
  me what you assumed.
- When you're finished, tell me the 3 things I should click to test it.

Note the "no user accounts" rule. Login is deliberately a later step (it's prompt 4 in the file below): getting the core of your app working first, then adding accounts, fails far less often than asking for everything in message one.

If your idea genuinely needs more than 3 screens, don't stretch this prompt. Use the Fable Kickoff PRD, a fill-in template where a cheap AI interviews you first and the finished spec goes to the builder in one message. That's the grown-up version of this step.

Step 3: the first build (touch nothing for 10 minutes)

Paste the kickoff prompt, send, and let it run. You'll see the builder narrate what it's doing and, after a few minutes, a preview of your app appears (the preview is the private, only-you-can-see-it version running inside the tool). Resist the urge to fire follow-up messages while it works; interrupting a build mid-stream is a classic way to get a half-finished mess.

1. 1

   Let it finish completely

   Wait for the builder to say it's done and list what it built. In Lovable and Bolt this takes 2 to 6 minutes for a small app.

2. 2

   Run its own test list

   The kickoff prompt asked for "3 things to click to test it." Click all three in the preview before you say anything else.

3. 3

   Check against your "done" list

   Go down your done criteria one by one. Mark each one works / broken / missing. That list is your afternoon's to-do list.

4. 4

   Change one thing at a time

   One message per change, and say what must NOT change. "Make the Save button green, touch nothing else" beats "can you improve the design."

What will go wrong (this section is not optional)

Something in your first build will break. Not because you did anything wrong: it's the nature of the tool. The difference between a fun afternoon and a rage-quit is knowing the failure list in advance. Here it is.

The one prompt to internalize from that table, because you'll use it 5 times this afternoon:

I got this error: [PASTE THE EXACT ERROR TEXT. If there's no error text,
describe what you see, e.g. "the screen is blank after I click Save"]

It happened when I: [WHAT YOU DID, e.g. "clicked Save on the new-session form"]

Do this in order:
1. Tell me in one plain-English sentence what caused it.
2. Make the smallest possible fix. Do not redesign, rename, or "improve"
   anything else while you're in there.
3. Tell me exactly what to click to confirm it's fixed.

Why the "smallest possible fix" line matters: an unscoped "fix it" licenses the builder to rewrite whole sections of a working app, and that's how a 1-line bug becomes a 40-minute detour. Small fix, verify, move on.

Step 4: put it online (one button, two checks)

Publishing (also called deploying) moves your app from the private preview to a real URL anyone can open. In Lovable it's the Publish button, top right, which gives you a link like yourapp.lovable.app. Bolt calls it Deploy, Replit calls it Publish, and in Claude you hit Publish on the artifact itself to get a share link.

Don't just smash the button, though. The classic first-publish fail is an app that works in preview and breaks live, because sample data or test settings didn't carry over. Make the tool check itself first:

I want to put this app online so anyone with the link can use it.

1. Walk me through publishing it from this tool, step by step, naming the
   exact buttons to click.
2. Before I publish: list anything that works in preview but will break in
   the published version (sample data, missing settings, test values), and
   fix those first.
3. After: tell me the URL, and the 3 things I should test on the live
   version, not just the preview.

Then the second check: phones. Most people who open your link will open it on one, and previews are desktop-shaped by default. Prompt 6 in the file makes the builder audit every screen at phone width (375px, a standard phone screen size) and fix overflowing text, off-screen buttons, and tap targets too small for thumbs. Send it, then open the live URL on your actual phone and tap through once.

Step 5: send the link to one person

Not optional, and not a feel-good flourish. Shipping to an audience of one changes your relationship with the whole practice: the app stops being a demo in a tab and becomes a thing that exists. Text the link to the person the app is for. Ask them one question: "what did you try to do that didn't work?"

Their answer is your first real feature request, and tomorrow's session. That loop (ship small, get one reaction, fix one thing) is the actual job, and you just did a full lap of it in an afternoon.

• [ ]App does the one thing your kickoff prompt promised, verified against your "done" list
• [ ]You hit at least one error and fixed it with the fix-it prompt (this is a feature of the afternoon, not a failure)
• [ ]Published: the app opens on a real URL in a private/incognito browser window
• [ ]Opens cleanly on your phone
• [ ]Link sent to one real person, one question asked

When you outgrow this (you will, fast)

This kit gets you from zero to one shipped app. Two signs you've outgrown it: your next idea needs more than 3 screens, or you're about to build something other people will rely on. Different problem, different kit:

Planning a bigger build: the Fable Kickoff PRD turns your idea into a full spec by having a cheap AI interview you one question at a time, then hands the whole thing to a frontier model in one message. It's the kickoff prompt from this page with a gym membership.

Understanding what you're building: the Architecture Interview makes the AI explain your own app back to you (what's stored where, what talks to what) so the next build is a decision instead of a dice roll.