Start building with AI: make one useful thing

Choose a job you can describe in one sentence

Look for something you already do with a small spreadsheet, a repeated message, a paper list or a series of browser tabs. Good first projects include a packing checklist, a practice timer, a palette picker and a tiny game. They have clear inputs and visible outputs. They can work without payments, accounts or access to someone else’s private files.

Write the sentence “For this person, my project turns this input into this useful result.” For a practice timer, that becomes: “For a musician practicing scales, my project turns a session length into timed intervals with a clear next exercise.” If the sentence needs several unrelated results, choose one. Save the rest in a later list.

Browse a few existing projects to notice the smallest satisfying interaction. Nicky Case’s LOOPY makes a feedback loop visible; Neal Agarwal’s games make a specific action immediately understandable. These are references for clarity and interaction, not claims that those creators used AI or a particular model.

Give the agent a brief it can check

A useful brief describes the user, the main action, the result and the boundaries. Include a worked example. State whether information should stay in the browser, whether the project must work on a phone, and what should happen when someone enters nonsense. Concrete requirements give you something to assess after generation.

The prompt below describes a hypothetical first build. It deliberately excludes a backend. A local timer does not need a database just because a coding agent can add one. Ask the agent to explain its proposed approach before changing files, then keep the first version small enough to inspect.

Build a browser practice timer for a musician. The user chooses 5, 10 or 20 minutes, enters three exercise names, and starts a session. Show the current exercise and remaining time. Include pause, resume and restart. Keep all information on this device; do not add accounts or external APIs. It must work with touch and keyboard. Before coding, list the files and acceptance checks. After coding, verify each check and report anything you could not test.

Choose where you want to work

An integrated building environment can handle more of the path from prompt to live link. A coding agent working in a repository gives you direct files and a workflow that can connect to different hosts. Claude artifacts offer another way to explore a small interactive experience, with sharing controls that you must check for your audience.

Choose the environment you can reopen, understand and maintain. Save the project in an account you own. Record where the files live and how you will publish changes. Current product access, sharing and hosting limits vary; a model subscription does not mean every deployment service is included.

• Compare Replit, Codex and Claude ↗
• Build a shareable site with Sites ↗

Change one thing, then check what happened

Run the smallest complete path before polishing the design. With the timer, enter three exercise names, start five minutes, pause and resume, then restart. Try an empty exercise name and reload the page. When something fails, tell the agent what you did, what you expected and what happened. A screenshot plus exact steps is more useful than “it is broken.”

Keep a known working version before each larger change. Ask for a focused repair and repeat the affected checks. If you ask for new fonts, a leaderboard, sound effects and account creation at once, you make it harder to identify the change that caused a problem. Resist adding a feature simply because the agent suggests it.

• Describe a failure as steps, expected result and actual result.
• Ask the agent to identify the cause before proposing a fix.
• Retest the original useful action after every meaningful change.

Finish with a real handoff

Publish to the audience you intend, then open the actual link in a signed-out browser and on a phone. Some preview and sharing links require an account or expire with a development session. A public launch needs a link that behaves as promised. Check the project title, a short description and a useful contact route.

Ask one person to complete the task while you stay quiet. Notice where they hesitate, then ask what they expected. Record those observations alongside bugs. Your next build decision should come from that evidence. The useful deliverable is a working link plus a short list of what you learned, rather than a claim that the project is finished forever.