Claude Code warm-up

Before we start the HADR project, build a tiny CRUD app from scratch. This is a one-hour warm-up: enough time to check that Claude Code and your development environment work, and to practise turning a small idea into running software.

Keep this app separate from the HADR starter repository. It can be disposable. It only needs to run on your computer; putting it online is a stretch goal.

The brief

Build a “boring tiny tool”: a small collaborative web app for a group or event you care about. It must have:

  • authentication, with at least two test users;
  • a database that still has its records after the app restarts;
  • create, read, update, and delete operations; and
  • one clear rule about who can see or change each record.

Keep to one main kind of record and one shared action. For example:

App Main record Shared action
Family to-do list Task Assign or complete it
Department outing board Suggestion Vote or RSVP
Team lunch shortlist Place Vote for it
Equipment list Item Borrow or return it
Small collection Entry Add a note or favourite it

Choose something useful to five people, not something meant for five million. Do not build a new Facebook or Instagram. An outing board for your own department is about the right size.

Start with product thinking

Take about five minutes to choose a group, situation, or interest. Do not choose features yet. Start with something such as family chores, department outings, team lunches, equipment lending, or a collection you care about.

Open Claude on the web. Use it as a product-thinking partner before you use Claude Code as a builder. Start a conversation with a small prompt:

Help me explore a useful app for [this group, situation, or interest]. Interview me one question at a time so that we can find a small, real problem worth solving. Do not suggest features or write code until we understand who has the problem and what they do now.

Stay in the conversation. Answer at least eight questions before asking Claude to write anything. Ask it to challenge a weak assumption or an idea that is too large. You should leave the interview knowing:

  • who the app is for;
  • what they do now and what gets in their way;
  • what a better outcome would look like;
  • which one workflow matters most;
  • what the app needs to remember;
  • what different users may see or change; and
  • what you will deliberately leave out.

If you already use agent skills, you can run an interview skill instead of writing your own prompt. Two examples are Brendan Graetz’s build-1-plan-product and Matt Pocock’s grilling. Both keep the work in conversation before implementation. A plain Claude chat is also enough.

Turn the interview into a PRD

When the idea is clear, use a separate prompt:

Turn our conversation into a one-page PRD for the smallest useful version of this app. Include the problem, target users, three to five user stories, the core journey, the main record and its fields, authentication and sharing rules, core features, acceptance criteria, and what is not in the first version. Do not add features we have not discussed. End by asking me what I would cut.

Read it. Change anything that does not sound like your idea, and cut anything you cannot demonstrate. Then create a new Git project for the app, save the result as PRD.md, make the first commit, create a GitHub repository, and push it. Keep this project separate from the HADR starter repository.

Build in small passes

Open the app folder in Claude Code. Do not paste one giant build prompt. Let the PRD hold the context, and give Claude one job at a time. For example:

  1. Read PRD.md. What is the smallest complete user journey we can build first? Do not code yet.
  2. Review its answer, then ask it to build and run that journey.
  3. Ask it to add the next CRUD operation.
  4. Ask it to test the app as both users and fix the most important failure.
  5. Ask it to compare the result with the PRD and tell you what is still missing.

Use a stack you know, or let Claude suggest a small one. A local database is fine. Production-grade identity, infrastructure, and deployment are outside this exercise.

Your checklist

Tick these off as you work. Your progress is saved in this browser.

If one part does not work, say so. A small, honest demo is more useful than a broad claim. If you fall behind, cut styling and features before cutting the core user journey.

Make a Claude Artifact

Once the app works, ask Claude to create and publish a public Artifact that explains:

  • who the app is for and what they do together;
  • the main record and its important fields;
  • how authentication and sharing work;
  • what works, what you cut, and what remains broken;
  • the prompt or decision that helped most; and
  • one thing you learnt while building it.

Include two or three screenshots if time allows. Keep it short enough to read in two minutes. Make the Artifact public, check its public link in a private window, and share that link with your video.

Record the walkthrough

Keep the video to 60–90 seconds. Show the app rather than its source code:

  1. Sign in as the first user and create a record.
  2. Sign in as the second user and show the sharing rule in action.
  3. Edit or delete the record.
  4. Open the Claude Artifact and name one thing you learnt.

Upload the video and Artifact link to the class submission board. Be ready to talk about one surprise, one useful prompt, and one thing you would change next.

Stretch goals

Only start these after the core path and video are complete:

  • deploy the app and share its URL;
  • add one automated test for the main journey;
  • use Claude Design to sketch one screen, then implement one small improvement from that design in Claude Code;
  • improve keyboard use, labels, and error messages; or
  • add one more collaborative action without adding another product.