Module 4: Building Your First Real App
Lesson 3

Building with Claude Code — Layouts, lists, forms, detail pages

The Build Loop

Building an app with Claude Code follows a predictable rhythm:

  1. Describe what you want — be specific.
  2. Watch Claude write the code.
  3. Check the result in your browser.
  4. Refine — what's working? What needs to change?
  5. Repeat.

You describe what you want; Claude writes the code. Your job is to be a clear director and a sharp reviewer, not a typist. This lesson gives you prompts and strategies for each kind of feature you'll build.

Feature 1: The Layout and Navigation

The layout is the shell around every page — usually a header with your app name and navigation links. Build it first, because everything else lives inside it.

Please set up the app layout with a clean navigation bar. The nav should:

  • Show the app name "Focus Dashboard" on the left
  • Have navigation links on the right: "Today", "All Tasks", "Notes"
  • Be sticky (stays at the top when you scroll)
  • Use a white background with a subtle bottom border
  • Be responsive (work on mobile too)

The main content area should have a max-width of 800px and be centered on the page.

Feature 2: A List That Displays Items

Almost every app has a list — tasks, posts, products, clients. This pattern is fundamental, so it's worth getting comfortable with it.

On the home page, build a task list component. For now, use hardcoded example data (we'll connect a real database later).

The task list should:

  • Display 5 example tasks (you can make up the titles)
  • Each task shows: a checkbox, the task title, and a delete button (trash icon)
  • Checking the checkbox visually marks the task as "done" (strikethrough text, reduced opacity)
  • Clicking the delete button removes the task from the list
  • The state should work within the page (no persistence needed yet)
  • Style it cleanly — similar to a Notion task list

Notice the phrase hardcoded example data. At this stage your data lives only in the page — it resets when you refresh. That's fine. You're building the interface first; you'll wire up a real database in a later module.

Feature 3: A Form That Adds Items

A list pairs naturally with a form to add new items.

Add an "Add Task" feature to the home page.

It should be:

  • A text input field and a "+ Add" button, side by side
  • Clicking "+ Add" (or pressing Enter) adds the new task to the list
  • The input clears after adding
  • If the input is empty, clicking "Add" does nothing (or shows a brief error)
  • Place this above the task list

Feature 4: A Data Display Card

Cards are great for showing summarized information at a glance — a highlighted box that draws the eye.

Add a "Today's Focus" card at the top of the home page. It should:

  • Have a slightly different background (maybe a light blue or light yellow tint)
  • Show a heading: "Top 3 Priorities"
  • Have 3 bullet points the user can click to edit (contenteditable)
  • Have a "Save" button that shows a brief "Saved!" confirmation when clicked
  • Feel like a highlighted callout — important but not overwhelming

Feature 5: A Simple Detail Page

A detail page is what a user sees after clicking a single item in a list — a focused view of just that one thing.

When a user clicks on a task title in the list, navigate them to a task detail page.

The detail page should:

  • Be at the URL /tasks/[some-id]
  • Show the task title as a large heading
  • Have a "Notes" text area below the title for additional task notes
  • Have a "Back to list" link at the top
  • Have an "Edit Title" button that makes the title editable inline
  • Keep this page simple — just a focused single-task view

The [some-id] in the URL is a dynamic route: one page file serves every task, swapping in the right one based on the ID in the address. Claude sets this up for you — you just describe the behavior.

Dealing With Errors

TypeScript and Next.js will sometimes throw red error messages in your browser or terminal. Don't panic — errors are normal, and Claude is very good at fixing them. The key is to paste the actual error text, not a vague description.

When your browser shows a red error overlay:

I got this error in my browser: [paste error]. How do I fix it?

When your terminal shows an error:

I got this error in my terminal when running npm run dev: [paste error]. What's wrong?

When the page just shows a blank white screen:

The page at /[route] is showing a blank white screen instead of my content. Here's the current code: [paste the page.tsx file]. What's wrong?

Iterating on Design

Design iteration works best when you're specific about what you don't like. "Looks bad" gives Claude nothing to work with. Describe the problem and, if you can, the fix.

Instead of: "The design looks bad."

Try one of these:

The task list feels too dense. Can you add more spacing between items, and make the checkbox slightly larger so it's easier to tap on mobile?

The colors feel off. Can you switch to a dark theme? Dark gray background (#1a1a1a), white text, and a teal accent (#0d9488) for the checkboxes and buttons.

This doesn't look professional enough. Can you look at what Linear (the project management tool) does for their UI and try to match that level of polish?

Keeping Track of What's Done

As you build, keep a simple running list of what works and what's next. You can even ask Claude to help you take stock:

Here's what we've built so far: [list]. What are the remaining items from my original spec? What should we tackle next?

A Word on "Good Enough"

Perfectionism kills projects. Your goal is a working app, not a perfect one.

If a feature is working at 80%, move on. You can always polish later. Finishing beats polishing.

Ask yourself: "If I showed this to someone right now, would they understand what it does?" If yes, move to the next feature.

Component Thinking

As your app grows, you'll start to see patterns — things that show up on more than one page. A nav bar. A card. A button style.

When Claude spots these, it often creates components: reusable pieces of UI saved in their own files. You'll see them appear in a folder like components/ or app/components/.

You don't need to understand how components work deeply yet. Just know:

  • A component is a reusable piece of UI.
  • Claude creates them when it makes sense.
  • If you want the same element on multiple pages, ask Claude to "make this a reusable component."

Summary

  • The build loop: describe → Claude codes → you review → you refine → repeat.
  • Be specific in every feature prompt — vague in, vague out.
  • Use hardcoded example data now; real data persistence comes in a later module.
  • Describe design problems precisely, not just "looks bad."
  • Paste the actual error text when debugging — that's what Claude needs.
  • Aim for working, not perfect — finishing beats polishing.