Week 5 of 6

Public web tool

Specify, build, test, and deploy one focused utility for a defined user.

Tool Shipper

What you can do after this week

You can specify a narrow problem, direct an AI builder at it, test the result, and ship it.

Start here

Watch and practise first

About 5–6 hours

What you hand in

A live URL anyone can use, a 3–5 minute walkthrough, and your specification and test log.

About 5–6 hours

Where it can live

v0 by Vercel — recommended
Lovable, Bolt, or Replit
Spec and test log in Google Docs

Make the link openable

A v0 or Vercel deployment URL is public by default. Open it on your phone before submitting — half of everything here is judged on a narrow screen.

Required contents

Everything the work must contain

6 items

01The specification, written before you built: target user, inputs and allowed values, the logic, expected output, validation and error states.
02Three test cases with their expected results.
03A test log covering normal, boundary, empty, and invalid inputs.
04One logic, usability, or accessibility defect you found and fixed — named explicitly.
05In the walkthrough: the problem, the tool working, and what your testing changed.
06Do not build diagnosis, dosage, or treatment tools.

Before you submit

Open every link in a private or incognito window before you submit. If it asks you to sign in or to request access, your reviewer will see exactly the same thing.

Links you will paste

3 separate links

Live tool URL
The deployed, working tool — not the editor or project page.
Link to your walkthrough
3–5 minutes showing the tool work and what testing changed.
Link to your specification and test log
One document holding both, including the defect you fixed.
Anything your reviewer should knowoptional
Optional. Known limitations, or what you would build next.

Acceptance rubric

What a reviewer checks

Published in advance

01The tool solves one specific problem for a clearly defined user.
02Inputs, calculations or transformations, validation, and edge states work correctly.
03The deployed tool is usable on mobile and the walkthrough explains testing and iteration.

The brief

How to build it

Week 5 - Ship and Test a Focused Web Tool

Capability

Define a narrow user problem, direct an AI builder, test the result, and publish a working utility. Visual polish cannot compensate for incorrect logic.

Build a tool connected to your domain thread.

Commerce or management: pricing comparison, break-even explorer, campaign planner, or vendor scorecard.
Humanities or social science: interview-theme organiser, reading estimator, event budget tool, or policy comparison aid.
Science or health: study planner, unit converter, evidence checklist, or public-information explainer. Do not create diagnosis, dosage, or treatment tools.

Specify Before Building

Write a one-page specification containing:

target user and problem;
inputs and allowed values;
transformation, calculation, or decision logic;
expected output;
validation and error states;
three test cases with expected results;
mobile behaviour and accessibility requirements.

Build and Test

Use v0, Lovable, Bolt, Replit, or another AI-assisted builder.
Provide the specification, not a vague request for a beautiful app.
Test normal, boundary, empty, and invalid inputs.
Check every calculation or transformation independently.
Test on a narrow mobile viewport and a desktop viewport.
Fix at least one logic, usability, or accessibility defect discovered during testing.
Publish a stable public URL.

Reading is free and always will be. Applying gets you the review — a person who reads what you built against the rubric above.

Apply to the program