← The First Build HackathonArrows or space to advance · F for fullscreen · ⌘P to save as PDFSessions

The First Build · Session 04 · Dates TBD

The First Build Hackathon

Build, verify, and demo one useful product

Ship AIPhoenix, ArizonaPress → to begin

Ship AIThe First Build Hackathon01/20

One user. One painful job. One working path.

The capstone is built for completion. Breadth loses to a narrow journey that works on a live URL.

Ship AIThe First Build Hackathon02/20

Today

  1. 01Choose the user, job, and finish line
  2. 02Form teams and lock the one-page brief
  3. 03Sketch the system and name the riskiest seam
  4. 04Build the first vertical slice before adding features
  5. 05Run mentor and verification rounds
  6. 06Freeze the deploy with time left to repair it
  7. 07Demo the live path and the evidence behind it
Ship AIThe First Build Hackathon03/20

Where we are

  1. Session 01From Idea to Build Plan
  2. Session 02Make It Real
  3. Session 03Direct the Agent
  4. Session 04The First Build Hackathon

Frame, build, engineer, ship. Today uses every prior checkpoint under one constraint: finish the core journey before time runs out.

Ship AIThe First Build Hackathon04/20

Act one

Lock the finish line

A hackathon brief is a boundary. It names the only path that must work and gives every tempting extra somewhere to wait.

Ship AIThe First Build Hackathon05/20

The one-page brief

  1. UserOne person with a specific situation — not everybody who could benefit.
  2. Painful jobThe thing they are trying to finish, not the feature you want to build.
  3. Core journeyThe shortest sequence from arrival to a useful outcome.
  4. DoneThe observable result the live demo must prove.
  5. Not todayEverything attractive that is outside that path.

If the brief cannot fit on one page, the build will not fit in the sprint.

Ship AIThe First Build Hackathon06/20

Scope by evidence, not ambition

Must proveCan wait
UserThe intended person can startEvery persona and role
ValueOne useful outcome completesThe full roadmap
DataThe core state persists correctlyEvery report and export
FailureThe riskiest case is handledEvery edge case
SurfaceThe journey is clear and usableA perfect brand system

A smaller promise fully kept is a stronger demo than a broad product that needs narration to survive.

Ship AIThe First Build Hackathon07/20

Start line: make the contract visible

~/your-product

write brief → name risk → create checkpoint

user + painful job lockedcore journey: 4 observable stepsriskiest seam: external data importbaseline commit tagged capstone-start

Create the brief, architecture sketch, risk, and definition of done before the first build prompt. Ask a mentor or another team to restate the journey back to you.

If they describe a different product, tighten the brief now. That disagreement gets more expensive after the first hour.

Ship AIThe First Build Hackathon08/20

Act two

Build vertically

Connect a thin path through every required layer first. A complete ugly path can be improved; five polished disconnected parts cannot be demoed.

Ship AIThe First Build Hackathon09/20

The capstone build loop

small turns
  1. 01Choose the next observable slice
  2. 02Plan and build only that slice
  3. 03Run the risk-matched checks
  4. 04Demo it to a teammate and commit

Every turn should leave the product more demonstrable than the turn before it. Infrastructure with no visible path is a warning.

Ship AIThe First Build Hackathon10/20

Build the riskiest path early

  1. InterfaceThe user can begin the real action.
  2. BoundaryThe request reaches the correct server or integration.
  3. StateThe useful outcome persists or returns correctly.
  4. RecoveryThe expected failure leaves a next step.
  5. DeployThe same path works outside your laptop.

Third-party APIs, auth, and unfamiliar data should be crossed before the comfortable styling work, not discovered during demo freeze.

Ship AIThe First Build Hackathon11/20

Mentor round: show the build, not the plan

~/your-product

slice 1 → check → browser → commit

core path reaches stored outcomementor found permission gapserver rule added; unauthorized path blockedcheckpoint: vertical-slice-01

Run the core journey in front of a mentor. Ask them to identify the riskiest assumption still unproven. Fix that before adding the next feature.

Mentors are most useful when they can react to evidence. Bring the live path, the failing check, or the confusing screen — not a ten-minute pitch.

Ship AIThe First Build Hackathon12/20

Act three

Freeze, verify, demo

A deploy freeze buys the time to test the product as a stranger, repair the path, and practice a demo that does not depend on luck.

Ship AIThe First Build Hackathon13/20

Demo-ready means evidence-ready

CheckReceipt
Live URLOpens in a clean browserNo local-only dependency
Core journeyCompletes from start to valueRecorded final run
DataCorrect state and owner persistRow or output inspected
FailureRiskiest case handledVisible recovery or safe rejection
RepositoryFinal state taggedKnown issues written down

A screenshot is not proof of a journey. Run the beginning, crossing, and outcome together on the final deploy.

Ship AIThe First Build Hackathon14/20

Freeze rules protect the demo

  • No new featuresAfter freeze, changes must repair the core journey or its evidence.
  • No secret improvisationDo not paste credentials into prompts, chat, screenshots, or client-side configuration.
  • No destructive shortcutsUse test data, explicit targets, and recoverable operations when cleaning or resetting state.
  • No hidden dependencyTest on another browser and connection before assuming the projector machine will match yours.

The capstone rewards a product that survives contact with the room, not a final-hour feature count.

Ship AIThe First Build Hackathon15/20

The three-minute live demo

  1. ProblemName the user and painful job in one sentence.
  2. JourneyUse the live product; keep narration behind the action.
  3. OutcomeShow the useful result and the state it created.
  4. ReceiptName the check or observation that makes the result credible.
  5. CaughtShare one thing the agent got wrong that the team found.

If the demo needs a feature tour, the core journey is not carrying enough of the story.

Ship AIThe First Build Hackathon16/20

The capstone artifact

~/your-product

deploy freeze → final run → tag release

live journey passed in a clean browserverification evidence capturedknown issues written without spinwrote 04-hackathon/retrospective.md

Save the live URL, final brief, verification evidence, demo notes, and a short retrospective. Name what shipped, what was cut, and what the agent got wrong that you caught.

The retrospective turns one intense build into a repeatable operating method for the next product.

Ship AIThe First Build Hackathon17/20

The First Build, complete

SessionCapability
01 · FrameBrief, project map, Git safetyMove fast with a way back
02 · BuildInterface, API, data, deploymentExplain and debug the full path
03 · EngineerAgent context, tests, verificationDirect a feature through evidence
04 · ShipLive journey and honest receiptsA product the room can use

You did not finish learning software. You built a reliable loop for learning through software.

Ship AIThe First Build Hackathon18/20

The demo is the product making its own argument.

Ship AIThe First Build Hackathon19/20

Next

Zero to Launch — the next program

The First Build gets the product working. Zero to Launch gives it positioning, distribution, measurement, and a public launch path. Bring the live URL and keep building from the same repository.

shipai.club · Free, always

Zero to Launch
Ship AIThe First Build Hackathon20/20
01/20