ISB AI Founders
Day 2 · 11:30 · guided build

Kimi Code 102

Wireframe it. Order it. Ship it.
Your product is live. Now map everything else.30 minutes
Where you are

Your product is live at a real URL. Now you map everything else.

This morning: project management, a build block, then you shipped to Vercel and pushed another round of features straight to that URL. Paper first, boxes and arrows, not because paper is slow, because paper is free to be wrong on. Fix it in pencil before you fix it in code.
The method · how do you know what screens?

You don't invent screens. You walk the user's journey.

① Arrive
What do they SEE first?
→
② Do
What can they DO, the one thing your product is for?
→
③ Result
What do they GET that proves it worked?
That's just your screen sentence from Day 1, SEE/DO/GET, written once per box. Most products this week need three or four of those, plus a couple more for the features the interviews demanded.
Step 1 · map the journey with post-its

One sticky per step. Lay the journey on the table.

LunchRush's user, start to finish, one sticky per thing they do:
Opens the link
→
Sees today's menu
→
Picks a meal
→
Taps order
→
Gets a pickup code
→
Shows it at the counter
SCREEN 1 · menu
SCREEN 2 · order
SCREEN 3 · code
The collapse move: steps that happen on the same screen get stacked into one pile. Each pile = one screen box. Six steps just became three screens. Nobody invented anything.
Step 2 · what a wireframe actually looks like

Boxes, not art. If you can draw a rectangle, you can wireframe.

SCREEN 1 · MENU
Today's date + LunchRush logo
Meal card · photo + name + price
Meal card
Meal card
[ TAP A MEAL ]
→
SCREEN 2 · ORDER
The meal, big
Pickup time picker
[ ORDER IT ]
→
SCREEN 3 · CODE
Giant pickup code
"Show this at the counter"
[ back to menu ]
Solid box = a screen. Dashed box = what they SEE. The dark button = the one thing they DO. The arrow = where it GETS them. One screen sentence under each box and the wireframe is done.
Exercise · Wireframe the whole product OFFLINE · screens closed

TEAM. Boxes and arrows, on paper.

10:00
1Draw every screen of your product as a box. One screen sentence per box: they SEE ___, they DO ___, they GET ___. Arrows show where each button goes.
2The bar for every box: what does the user DO here? No answer, erase it. Logos and decoration don't get a box.
3Ugly is correct. A wireframe is a plan, not a painting.
4Number the boxes in rough build order. Screen one, the one already live, is already number one.
10:00
Wireframe on the desk (photo → TEAM FOLDER). Next: turn it into build order lines.
The build order, extended

Every box on the wireframe becomes one more line on your build order.

Rule 1Smallest shippable slice first. Not the whole screen at once, the smallest piece a user could actually try.
Rule 2Number every item. The order on the wireframe is a rough draft, this is the real one.
Rule 3Feature 1 is already live, at your real URL. Cross it off before you start. That's momentum, use it.
LunchRush · build order
✓1. Shortest-line screen with refresh
2.Tap a station to see its full menu
3.Thumbs-up button, counts taps per station
4.Real wait times instead of placeholder numbers
Exit ticket
Leave with ·A wireframe of the whole product + your build order, extended, item 1 already shipped.
Decided ·What order you're building in, and why that feature is next.
Bring next ·Lunch, then 13:15 design systems. The 13:45 build block builds straight off this order, and 14:30 interviews test what your wireframe assumes.