Build an App — cheat sheet

The one idea: Two windows. You think in the cheap one and build in the expensive one, and you never mix them up. The handoff between them is a single detailed prompt the chat window writes for you.

• Window 1 — ChatGPT / Claude (think): talk through the idea, cut it down, write the build prompt, diagnose what broke.
• Window 2 — Lovable / Rork (build): paste the build prompt, watch it build, ask for one change, apply the fix.

The 4-step method

• 1. Shape — in Window 1, describe the idea and let it interrogate you. Land on the real problem.
• 2. Cut — three screens, one list of saved data. If it won't fit, it's still too big.
• 3. Hand off — make Window 1 write a single build prompt. Paste it into Window 2 once.
• 4. Iterate — one specific change per message. When it breaks, diagnose in Window 1 first.

Step 1 · Shape it (Window 1)

I'm building a small web app this weekend for the 313 Buildathon.
Pillar: [paste the pillar description].
Who it's for: [one real person, one real problem].

Help me get this down to something buildable in two days by
someone who doesn't code. Ask me what you need to know first, then
tell me the smallest version that still solves the real problem.

Step 2 · Cut it down (Window 1)

Give me the 3 screens this needs — no more than 3. For each one:
what a person sees, and the one action they can take.

Then list exactly what data the app has to remember between
visits, with the fields for each thing.

Step 3 · The handoff prompt (Window 1 → Window 2)

This is the highest-value move on the sheet. Copy it exactly.

Now write me one single detailed prompt I can paste into Lovable
to build the first version of this app. Include:
- who it's for, in one line
- the 3 screens, named, and what's on each
- the data it stores and the fields
- what happens when someone taps the main button
- the look and feel: plain, high contrast, big tap targets,
  works on a phone

Write it as instructions to a builder, not as a description back
to me. One prompt, no commentary.

Read it. If a screen or a field is missing, ask for the fix in Window 1. Then paste into Window 2 — once.

Step 4 · Iterate (Window 2)

One change per message. Name the element and the behavior.

Make the Submit button save the report to the list on the
Reports screen.

On the Reports screen, show newest first, and put the status
badge to the right of the address.

When something breaks, go back to Window 1:

My app does [X] but I need it to do [Y]. Here's the error it
showed: [paste it]. Give me the exact one-sentence instruction
to paste into Lovable to fix this.

Credit discipline

• Submit the credits intake form before you need it. That's what allocates your Lovable credits — use the same email you signed into Lovable with.
• Chat is cheap. Build messages are the scarce resource. Never brainstorm in Window 2.
• Every vague message ("make it better") costs the same as a good one and buys a surprise.
• Budget: most of your credits Saturday morning on version one, a handful Saturday afternoon, hold a reserve for Sunday — something will break.
• Sunday afternoon is for rehearsing, not building.

Quick reference

• Lovable (lovable.dev) — web apps. New project → paste the build prompt → it generates and shows a live preview. Share / Publish gives you the public URL that *is* your demo. Say "make the design responsive" so it works on phones. Credits are per message. Code export via the GitHub button.
• Rork (rork.com) — same idea for mobile (Expo / React Native). Preview on your own phone via the Expo app. Choose only if native is the point; expect a free tier, not event credits.
• ChatGPT / Claude — Window 1. Keep one chat per project so it remembers everything.

Event credits: submit the intake form to get your Lovable credits allocated — full picture on the Builder's Kit.

Glossary

• Build tool — a tool that turns a written description into a working app. Lovable, Rork.
• Prompt — the instructions you paste. In Window 2 a prompt is a work order.
• Responsive — the layout adapts to phone screens. Ask for it explicitly.
• Deploy / publish — putting your app at a public URL. In Lovable it's one button.
• Backend / database — where the app saves things between visits. Lovable will set one up when your prompt says data must be remembered.
• Export — downloading the actual code so you can keep building outside the tool. Ask a coach.

Worked example — Block Fix · reporting broken things on your street

1 · The build prompt Window 1 wrote

Build a mobile-friendly web app called Block Fix for Detroit block
club coordinators who track broken things on their streets —
streetlights out, illegal dumping, sidewalk hazards — and need one
shared list instead of a group text.

Three screens:

1. "Report It" (home). A short form: address or nearest cross
   street, a category dropdown (Streetlight, Dumping, Sidewalk,
   Water, Other), a one-line description, an optional photo, and
   the reporter's first name. One big Submit button. After
   submitting, show a confirmation and go to the list.

2. "The List". Every report, newest first. Each row shows the
   category icon, the address, the description, how long ago it
   was reported, and a status badge: New, Reported to City, or
   Fixed. Tapping a row opens the detail view where the
   coordinator can change the status and add a note.

3. "This Month". A simple summary: how many reports came in, how
   many are still New, and a count by category. No charts needed —
   big numbers with labels.

Data to store for each report: address, category, description,
photo, reporter name, created date, status, coordinator notes.

Navigation: a bottom bar with the three screens.

Look and feel: plain and high-contrast, large tap targets, readable
at arm's length on a phone in daylight. No animations. Use one
accent color for the Submit button and the status badges. Make the
design responsive.

2 · The first three follow-up messages

On The List, make the status badge tappable so the coordinator can
change status without opening the detail view.

On Report It, make the photo optional and clearly labeled optional,
and keep the form usable if someone denies camera access.

On This Month, add one number at the top: the average days from
New to Fixed.

3 · What broke, and the fix

Window 1: My app saves reports but after I refresh the page the
list is empty. Here's what Lovable showed me: [pasted error].
Give me the exact one-sentence instruction to fix this.

Window 2: Store reports in the database instead of in browser
state so the list persists after a page refresh.

4 · What you hand a judge

A public URL. You open it on their phone, submit a report about the streetlight outside the venue, and show it land on the list with a New badge. Then you show This Month and say what a year of that data would tell the city.

That demo takes ninety seconds and it lands every time.