A path from the foundations to useful work

Build and maintain a useful first page

Scope a small website, choose only the needed services, inspect the result and leave a recoverable handoff.

19 connected lessons and a capstone
Inspect the capstone

Build the skills, then put them together

These lessons reuse the common curriculum. Open any lesson, and return to the capstone when you are ready to assemble the outputs.

Your saved progress loads in this browser.

Completion records your own checks. It is not a test score or a certification. You can open any lesson.

Start the first lesson
  1. Understand models, assistants, agents and automations
  2. Define the result before choosing the tool
  3. Decide what AI, software and people should do
  4. Map the work people actually do
  5. Choose a first task you can judge
  6. Find the constraints that change the plan
  7. Choose a platform from the work and constraints
  8. Write instructions that survive the handoff
  9. Give every agent a job and an owner
  10. Design the check and the way back
  11. Write a pilot you can actually evaluate
  12. Test ordinary work, messy work and when to stop
  13. Review the output against evidence, not confidence
  14. Measure the whole job, including review
  15. Decide whether to adopt, adapt or stop
  16. Leave a decision someone else can understand
  17. Turn the accepted workflow into a playbook
  18. Keep the workflow useful after launch
  19. Expand the scope only when the evidence transfers

Your capstone exercise

Make a useful page and prove you can change it

Synthetic capstone: create a local information page for a fictional community garden. It explains the garden, lists two clearly labeled sample events and offers one obvious next action. Begin with a local page and sample content. No accounts, database, payment or form collection are required. Publishing is a separate deliberate step after target, access, content and operating responsibilities are understood.

Work with an approved public input or a clearly labeled fictional example. Completing the exercise does not authorize access to real systems or publication.

Prepare the inputs

  • Write a small approved content pack: garden purpose, two sample events and the intended visitor action. Clearly mark the sample details.
  • Choose a project folder and preserve any existing files; give the builder a bounded set of files to own.
  • Prepare a brief stating the audience, mobile reading needs, content, allowed actions and acceptance checks.
  • Identify the code-history owner and, if publishing, the authorized hosting account, target environment and cost owner.
  • Use the existing stack guide to explain each chosen service. Exclude shared storage and login until an actual requirement justifies them.

Do the work

  1. Define the page's useful outcome and write an initial brief. Have the assistant ask about conflicting or missing facts rather than invent them.
  2. Build the smallest local page. Inspect the actual output in a browser at phone and desktop widths, using keyboard navigation and the primary link.
  3. Save an inspectable Git checkpoint and review the changed files. Explain the difference between a local commit and a remote push.
  4. Run normal-content, long-text and conflicting-date cases. Check wrapping, useful headings, visible focus, valid destinations and honest handling of missing information.
  5. Make one small follow-up change, inspect its diff and repeat the relevant checks. Practice restoring the prior working change on this sample project.
  6. If choosing to publish, verify the target environment and who can access it first. A first Vercel deployment may be production. Open the actual final URL and rerun the user-facing checks.
  7. Write the decision record, deployment status and maintenance playbook. Include the output location, update instructions, cost owner, recovery steps and requirements that would trigger a new platform decision.

Check what you made

  • A visitor can understand the page and complete its intended action on a phone.
  • All sample details are labeled; no testimonial, registration count or real event claim is invented.
  • The learner can explain every required service and why a database or login was omitted.
  • The changed files, working checkpoint and recovery steps are inspectable.
  • Published status is claimed only when the actual target URL has been opened and checked; a local-only result is labeled accurately.
  • The handoff lets another person make a small change and knows when to ask for help.

Take these outputs with you

  • A working local page with its content pack and brief.
  • An inspectable code checkpoint and a verified small follow-up change.
  • A check record, recovery notes and explicit local/deployed status.
  • A platform decision and maintenance playbook with owners.

Adapt the capstone to your context

Owner-led business or small team

Use one builder and one self-review pass. Choose a managed setup you can maintain and keep a working checkpoint before experimenting.

Department or growing team

Assign one owner per file or isolated change, then integrate and review the combined result. Keep release authority explicit.

Large or complex organization

Use approved repositories, accounts and deployment processes. Test the intended environment and access; adding real user data or authentication requires separate data and authorization checks.

Take this capstone into your plan

Use the exercise as a starting point. Add a real owner, baseline, permissions and review process in My AI Plan.

Use one builder and one self-review pass. Choose a managed setup you can maintain and keep a working checkpoint before experimenting.

Open My AI Plan

Keep useful references nearby

Explore another learning path