Course A · Module A4 Build · Lesson 14 of 17

Build & Ship a One-Page Tool

Generate your tool, preview it, and put it live on the real internet at a public URL — your first "I made real software" moment.

~20 min · Have your A13 build brief ready to paste · Prereq: A13 Write the Build Brief

You've planned what to build. Now you build it. This lesson is hands-on from the first paragraph: you'll open Lovable or Bolt, paste your brief, generate a working first version, iterate in small steps, and then deploy it to a real public URL that you can share with anyone. Your single win: by the end of this lesson you will have shipped a piece of software you made — not a template someone else built, not a prototype that only runs on your laptop. A live tool at a real address.

Pick your builder

Two tools do this job well for non-technical founders right now. Either works for this lesson — pick one and stay with it.

Lovable (lovable.dev)

Strong on polished UI out of the box
Built-in deploy with one click
Free tier for experimenting; paid credits for longer sessions
Best for tools that look client-ready from day one

Bolt (bolt.new)

Fast generation, strong on React apps
Generous free tier to start
Deploy via Netlify drop or StackBlitz
Best for prototyping quickly when looks matter less than function

Both tools meter your usage in credits. You spend credits each time the AI generates or rewrites code. This matters: large, vague requests burn more credits than small, specific ones. Keeping your requests narrow is good engineering and good economics.

Build in small steps — not one giant prompt

Think of the builder like a skilled contractor you're directing over the phone. You wouldn't say "build the whole house" in one call and wait a week. You'd say "pour the foundation," walk over and check it, then say "frame the walls." Small steps, eyes on the result after each one.

Same rule here. One specific request → check the preview → next request. The tighter the loop, the less you have to undo.

The build-and-ship steps

Follow these in order — don't skip ahead

Open the builder and start a new project. Lovable: click "New Project." Bolt: go to bolt.new. You get a blank canvas.
Paste your build brief as the first prompt. Copy your entire A13 brief — all seven fields — and paste it as your opening message. Do not add extra requests yet. Send and wait.
Preview what it generated. The builder shows a live preview. Click through every element. Does the input work? Does the output appear? Write down what's wrong before you say anything to the AI.
Iterate with one request at a time. Fix the most important problem first. One sentence, specific: "The output text is not appearing after I click the button. Fix only that." Check again. Repeat. Never ask for two changes in one message.
Test with a real example from your brief. Use the exact "done looks like" test you wrote in A13. Paste your real input. Does the output match what you described? If yes, you're done with v1. If not, one more targeted fix.
Deploy to a public URL. Lovable: click "Deploy" (top right) — your app gets a *.lovable.app address instantly. Bolt: click "Deploy to Netlify" or use the StackBlitz share link. Either way you get a real HTTPS URL.
Test on the live URL. Open the public URL in a fresh browser tab — not the preview. Run your "done" test again. If it passes: you shipped.

Credit discipline: before you send any message to the builder, read it and ask: "is this one change or two?" If it's two, send two separate messages. A focused request takes fewer tokens, produces less broken code, and is easier to undo if it goes wrong. Vague or multi-part requests are the fastest way to burn your credit quota on rework.

When the first version isn't quite right

It almost never comes out perfect. That is fine — it is expected. Here's the triage order:

Core job brokenThe input/output doesn't work at all → one focused fix prompt, or revert and re-paste the brief.

Output wrongThe text or data is off → describe exactly what you got vs. what you wanted, in one sentence.

Looks wrongCosmetic issues (color, layout) → address after the core job works. Never prioritize looks over function in v1.

Something new neededYou want to add a feature → write it in a new brief field first, then ask. Scope creep is still a risk inside the builder.

If after three targeted fix attempts the same thing is still broken, stop. Lesson 16 covers the debugging loop properly. For now: celebrate what works, note what doesn't, and move on. A tool that does 90% of the job is infinitely more useful than a perfect spec with no tool.

Check yourself

Answer before opening — recalling it is what makes it stick.

Why do you paste the entire A13 brief as the first prompt, rather than writing a new short prompt?

Because the brief already contains all the decisions. Who it's for, the one job, the input, the output, what done means, what to leave out — those are exactly the facts the builder needs to generate a focused first version. Rewriting a shorter prompt just risks losing precision you already worked to define.

You ask the builder "make it look better and also fix the button." What's wrong with that?

It's two changes in one request. When two things change at once and something breaks, you don't know which change caused it. Send one message per change, check the preview, then send the next one.

Your app works perfectly in the builder preview but throws an error at the live URL. First move?

Re-deploy, then re-test. Sometimes the preview runs a slightly different version than what was deployed. Click Deploy again to push the latest version, then check the live URL fresh. If it still errors, that's a debugging job for Lesson 16.