Week 2
The Build
Use a harness to create the first product while learning how to prompt, test, and get unstuck.
Workflow
Small tasks beat giant prompts.
Members learn to ask for one visible behavior at a time, then make the harness run the app and verify it.
The course keeps code explanations optional and focuses on product behavior, screenshots, tests, and command output.
A useful harness task has four parts: the user goal, the current context, the exact behavior to add or fix, and the acceptance check. Long vibes without acceptance checks are how prototypes drift.
The builder stays in control by sequencing work: plan, edit, run, inspect, commit the decision, then ask for the next smallest behavior.
Context
Give the harness a product brief before code.
Before a build session, paste the buyer, problem, thin promise, user path, constraints, and known exclusions. The harness should understand the job before touching files.
Ask for a route, component, and data plan in plain English. If the plan adds extra dashboards, auth, billing, or automation too early, make it simplify before editing.
Keep a decisions note open. Every time the harness makes a product choice, record the reason so future sessions do not rediscover the same context.
Spec
Build one path through the product.
The thin build is one end-to-end path: a page loads, the user enters or chooses something, the app produces a result, and the result can be saved, copied, emailed, or acted on.
Manual operations are acceptable. If the first customer can get value while the founder manually handles fulfillment, support, or review, that is often better than building a fragile automation.
The spec should include disabled states for any provider that is not configured. A serious prototype does not pretend checkout, auth, storage, or email work before they are verified.
Verification
Test behavior without reading code.
The member does not need to audit every implementation detail. They need to know the app starts, the page loads, the user path works, invalid inputs fail clearly, and mobile does not break.
Ask the harness to run the app, run focused tests if they exist, and summarize the exact verification commands. If a command fails, the failure becomes context for the next prompt.
Screenshots, local URLs, response codes, and database rows are better than confidence. The course trains members to ask what evidence proves the behavior.
Unsticking
When it breaks, preserve the facts.
A good recovery prompt includes the intended behavior, exact error, recent change, and what has already been tried.
Members should learn when to restart from a clean plan and when to keep iterating in place.
Do not ask the harness to rewrite the app because one page is broken. Ask it to inspect, identify the likely cause, make the smallest fix, run the relevant check, and explain how to verify.
Restart only when the plan is incoherent, the app cannot run after repeated small fixes, or the current implementation no longer matches the thin promise.
Boundary
Know what stays manual.
Week 2 is not the week to perfect billing, onboarding, analytics, or community operations. Those rails matter, but the first product proof is whether the core job helps a real person.
Write down every manual step: who receives submissions, who sends follow-up, who grants access, what is checked before sharing, and what breaks if usage doubles.
Manual notes become the Week 3 shipping checklist and the first support FAQ.
Build the thin version
- Write a one-page product spec from the Week 1 promise.
- List the first user path, acceptance checks, and known exclusions.
- Ask the harness for a route, component, and data plan before editing.
- Implement one user path end to end.
- Run the app locally and inspect desktop and mobile behavior.
- Use the unsticking protocol for every error instead of vague retries.
- Write a manual smoke test and a list of manual operating steps.
Prompt starters
- Here is the buyer, problem, promise, and first user path. Propose the smallest route, component, and data plan in plain English before editing.
- Implement only this behavior: [behavior]. Acceptance checks: [checks]. Do not add auth, billing, dashboards, or integrations unless required for this path.
- Run the app and inspect the result before changing more. Tell me the local URL, what you checked, what passed, and what still looks broken.
- The intended behavior is: [behavior]. The actual behavior is: [what happened]. The exact error or symptom is: [error]. Recent changes: [summary]. Make the smallest fix and run the relevant check.
- List the manual steps still required to support the first user safely.