Permission to Build

Most AI courses hand you ingredients and call it dinner. We are cooking the whole meal.

Build one real lead intake and routing app from a blank idea to a deployed system with planning, context, test cases, token budgets, logs, alerts, retries, privacy controls, and a rollback plan.

Course

14 complete modules

Capstone

A deployed Lead Relay app

Progress

0 of 14 complete

Start the open lessonsUnlock the remaining 12 modules
00See the Finished System Before You Touch the CodeWalk one lead from form submission to human follow-up and learn which parts are rules, which part uses AI, and which parts stay human.

Module 00: See the Finished System Before You Touch the Code

What you finish

You can explain the complete Lead Relay flow, its boundaries, and its failure states in plain English before an AI coding agent writes anything.

Most build tutorials start by creating a project and installing packages. That feels productive because text flies across the screen. It also makes it easy to build the wrong thing faster. We are starting with the finished customer experience and working backward.

Lead Relay has one job: make sure a person who asks for help gets a truthful next step and the team gets enough context to respond. The app is not a CRM, an autonomous salesperson, or a robot that gets to make promises. Narrow is good. Narrow is how you finish.

A valid request moves through a visible chain: receive, validate, normalize, check for duplicates, score, route, summarize, save, notify, and review. Every stage produces evidence. If notification fails, the lead still exists and the failure becomes visible. A green success message without a saved record is not success.

The key design choice is separating rules from judgment. Email validation, consent, scoring, deduplication, and route selection are deterministic. The same input should produce the same output every time. AI only summarizes messy notes, where language judgment is useful. A human handles exceptions, sensitive claims, and the actual sales conversation.

The order ticket

A restaurant ticket tells the kitchen what was ordered, what cannot be included, who owns each station, and when the plate is ready. Lead Relay works the same way. The intake record is the ticket. Routing rules assign the station. Logs tell us whether the plate left the kitchen.

Where it stops: The analogy stops when judgment becomes sensitive. A kitchen can remake fries automatically. A business should not automatically promise pricing or legal eligibility because a model sounded confident.

Build steps

  1. 01

    Walk the happy path

    Use a sample lead with consent, 80 monthly repetitions, 7 hours lost per week, a 30-day timeline, and a supported workflow type.

    • Write the raw form input at the top of the page.
    • Calculate the visible score: 2 for volume, 2 for hours lost, 2 for timeline, and 1 for supported workflow.
    • Mark the route as priority and list the visitor response, team alert, and database events that should exist.

    Artifact update: Add a solid line through the successful path on system-map.md.

  2. 02

    Walk a rejection path

    Remove contact consent from the same lead. The system must stop before scoring or outbound follow-up.

    • Mark the request as rejected with a safe user-facing explanation.
    • Record which minimal event may be stored for abuse prevention and which personal fields should not be retained.
    • Confirm that no email or team notification is sent.

    Artifact update: Add the rejected branch and its stop condition to system-map.md.

  3. 03

    Walk a provider failure

    Assume the lead is saved and routed, but the email provider returns a temporary 429 rate-limit response.

    • Keep the lead state and delivery state separate.
    • Move the delivery job to retry instead of telling the visitor everything was sent.
    • Add the event, log, retry schedule, and alert owner to the map.

    Artifact update: Add a dashed failure branch from notification to retry and human review.

  4. 04

    Label who decides

    Every box needs an owner: deterministic code, AI, or a human.

    • Circle deterministic decisions such as validation, scoring, and route thresholds.
    • Box the AI summary step and write exactly what it cannot do.
    • Underline pricing, sensitive replies, and exceptions as human decisions.

    Artifact update: Add a three-item owner legend to system-map.md.

Exact examples

The final request flow

text
Visitor form
  -> POST /api/leads
  -> validate + normalize + consent check
  -> duplicate check
  -> deterministic score + route
  -> optional AI summary with strict schema
  -> save lead + immutable event
  -> enqueue visitor email + team alert
  -> retry transient failures
  -> human reviews priority and exception queues

This is the spine of the course. Every later module makes one part of this flow real and testable.

Your exercise

Trace three leads on paper

Create one successful priority lead, one request without consent, and one valid lead whose email delivery fails. Draw what the user sees and what the system records for each.

  1. 01Start each trace with exact field values, not labels such as good lead or bad lead.
  2. 02Write every state transition beside the arrow that causes it.
  3. 03Label every decision as deterministic code, AI, or human.
  4. 04End each trace with observable evidence: a record, event, delivery status, review item, or rejection response.

Deliverable: Lead Relay system map

docs/system-map.md

Acceptance checks

  • The map separates lead state from notification delivery state. A saved and routed lead can visibly exist while its delivery job is retrying or failed.
  • AI cannot change consent, score, route, or send a message. Those decisions are assigned to deterministic code or a human on the owner legend.
  • Every path ends in an observable state. The three traces end with named records, events, queue items, or user-facing rejection responses.
  • A provider failure is not shown as success. The notification branch includes retry, final failure, and human review.

Common ways this goes sideways

  • Starting with the visual form and leaving the server behavior vague.
  • Calling the whole flow AI even though most steps are ordinary rules and database work.
  • Treating a successful API response as proof that the lead was saved and the email was sent.
  • Adding extra features such as login, dashboards, or chat before the first lead can move end to end.
01Pick a Problem Small Enough to FinishTurn a fuzzy app idea into one user, one painful moment, one trigger, one useful result, and a list of things you refuse to build yet.

Module 01: Pick a Problem Small Enough to Finish

What you finish

You have a one-page product brief that lets another person decide whether the first version is complete without reading your mind.

The first product-killing phrase is usually something like, I want an AI platform for sales. That is not a buildable problem. It does not name the person, the moment they are stuck, the input, the output, or what good looks like.

Lead Relay starts much smaller: when an operator submits a workflow problem, capture enough structured context to route the request and send a useful next step without someone copying form data into a spreadsheet. That sentence gives us a trigger, user, pain, and outcome.

A useful scope has edges. Version one does not close deals, scrape profiles, create proposals, or replace a CRM. Those ideas are not bad. They are simply not allowed to delay the first complete path.

Do not invent impressive metrics. Define measurements the product can actually observe: valid submissions saved, route chosen, notification delivery state, duplicate rate, time from receipt to review queue, and manual overrides. Baseline the real system later before claiming improvement.

Build steps

  1. 01

    Name one user in one moment

    Avoid audience soup such as founders, marketers, sales teams, and creators.

    • Write one primary user: a service-business operator asking whether a repetitive workflow is worth automating.
    • Describe the exact moment: they just reached the site after another week of manually moving the same information.
    • Write what they need next: a useful acknowledgment and a clear route, not a generic thanks message.

    Artifact update: Complete the User and Painful moment sections of product-brief.md.

  2. 02

    Define the job and the finish line

    The job should describe a change in the user's situation, not a feature list.

    • Write the trigger as a form submission with exact required fields.
    • Write done as a saved lead, visible route, truthful response, and review or education next step.
    • List evidence for done: database row, lead event, delivery job, and user-facing state.

    Artifact update: Complete the Trigger, Job, Definition of done, and Evidence sections.

  3. 03

    Set non-goals before they become features

    A non-goal protects the product from exciting detours.

    • Copy the reference non-goals and explain why each is deferred.
    • Add any idea you are personally tempted to build, such as a full CRM or autonomous outreach.
    • Define the condition that could justify revisiting each idea after launch.

    Artifact update: Add at least five non-goals with revisit conditions.

  4. 04

    Write observable acceptance criteria

    Words such as fast, clean, smart, and user-friendly cannot pass or fail a test.

    • Replace vague qualities with exact behavior for valid, invalid, duplicate, and failed-delivery requests.
    • State what the user sees and what the server stores.
    • Include one privacy criterion and one accessibility criterion.

    Artifact update: Add version-one acceptance criteria that can be checked without asking an AI whether the app feels good.

Exact examples

One-page product brief template

markdown
# Lead Relay product brief

## Primary user
A service-business operator describing a repetitive workflow.

## Painful moment
They have just lost another week to the same manual handoff and want a useful next step.

## Job
Capture the request, validate consent, route it with visible rules, and send a truthful response.

## Trigger
A POST request from the public lead intake form.

## Definition of done
- Valid lead saved with a correlation ID
- Score and route stored with reasons
- Visitor response queued or delivery failure visible
- Team review item created when required

## Non-goals
- Autonomous sales conversations
- Full CRM replacement
- Private-data scraping
- AI-controlled routing

## Measurements
- Valid submission rate
- Duplicate rate
- Time to review queue
- Notification success and retry rate
- Human route override rate

## Version-one acceptance criteria
Write exact pass or fail behavior here.

Keep this to one page. If the brief needs twelve pages, the first version is probably still too large.

Your exercise

Write the version-one contract

Complete the Lead Relay product brief as if you are handing the build to a capable person who is not allowed to ask what you meant.

  1. 01Use the template and replace every vague adjective with observable behavior.
  2. 02Include the exact valid-lead happy path in five sentences or fewer.
  3. 03Add behavior for invalid input, duplicates, AI failure, and notification failure.
  4. 04Add five non-goals and one revisit condition for each.
  5. 05Read it aloud. Remove any sentence that sounds impressive but cannot guide a build decision.

Deliverable: Version-one product brief

docs/product-brief.md

Acceptance checks

  • The brief names one primary user. The user statement does not combine founders, creators, marketers, and sales teams.
  • Done is observable. A reviewer can point to the lead row, event, route reasons, delivery state, and user-facing result.
  • The first version has hard edges. At least five tempting features are listed as non-goals with revisit conditions.
  • Claims stay truthful. Measurements describe what will be observed after launch and do not claim an unmeasured conversion or time-saving result.
  • The brief can drive tests later. Each acceptance criterion can become a deterministic assertion or a named human review step.

Common ways this goes sideways

  • Writing a feature wishlist instead of a user problem.
  • Using AI-powered as the mechanism without saying what the AI actually does.
  • Skipping non-goals because every idea feels small on its own.
  • Promising faster response or higher conversion before measuring the current baseline.
  • Defining success as the page looks good or the model says it works.
Checking access...

Still inside

  • 02 Context Is the Allergy List
  • 03 Write the Plan Before the Code
  • 04 Break the Build Into Vertical Slices
  • 05 Vibe Code Without Playing Roulette
  • 06 Turn Repeated Work Into Reusable Skills
  • 07 Test Rules With Cases, Not Vibes
  • 08 Evaluate AI Without Letting AI Grade Itself
  • 09 Do Not Bring the Whole Pantry to Make One Sandwich
  • 10 Install Smoke Detectors: Logs, Alerts, and Retries
  • 11 Protect Secrets, PII, and Consent
  • 12 Deploy With a Way Back
  • 13 Capstone: Ship Lead Relay and Prove It Works

Showing 2 of 14 modules on this device.