Describe how you would build a working prototype of an AI feature in a day.

How to answer this, stage by stage

Nobody is grading whether you land on exactly eighteen test runs. They're grading whether you cap the wiring before you start, whether you can defend the hour-by-hour math, and whether you close with a number the room can check. Seven moves get you there.

Let's learn

The product is an assistant inside a calendar app that reads a messy scheduling thread and proposes three real times, instead of another round of "does Tuesday work for everyone."

Before a prototype gets scoped like this, a builder given "one day" usually just starts. No hour budget, no named interaction, just an open editor and a deadline of five o'clock. That habit costs almost nothing on a feature that's mostly familiar. It costs the whole day on one that isn't, because there's no block reserved for finding out where it actually breaks.

Here's the turn. The extra hours spent polishing a screen are not the real cost. The real cost is what those hours take from the block that was supposed to prove the idea. A prototype with a nice screen and two test runs behind it has not actually been tested. It has been decorated.

At its worst, that gap shows up in the room. Someone in the review pastes in their own real thread, the one you never tried, and the assistant returns a time that's already booked. Now the room doesn't just doubt the polish. It doubts whether the idea works at all, and a bad first look is hard to undo.

The choice I would take back. On an earlier prototype, I didn't check whether an existing screen could carry the new feature before I started. I opened a blank file and began building a panel from nothing, because it felt like the obvious way to start the day. That was fine on features where a new screen was genuinely needed. It was the wrong first move on a feature the product already had a home for.

What I would leave alone. The result card's visual polish, the exact spacing, the little animation when a time slot appears, doesn't matter for a one-day proof. Nobody in a scoping review is grading whether the card slides in smoothly. They're checking whether the three times it proposed were actually free. Spend zero extra hours there.

The lesson. A day with no hours written down isn't a fast day. It's a day where the block that needed protecting the most, real testing, is the one with no claim on any of the time.

Now here is the same thing as a story

The short version is above. Read on if you want to feel why the hour budget is the whole decision, not a formality before the real work starts.

Corinne Vasseur has shipped four features at Daybook, a calendar app used by small teams who are sick of scheduling meetings by email. She's good under a deadline. Ask her to turn around a proof-of-concept and she'll usually have something on screen before lunch.

Her manager gave her one day, a Monday, to build a working prototype of an AI scheduling assistant before Tuesday's roadmap review. Not a slide deck. Something the leadership team could actually try, pasting in a real thread and watching it propose times.

Corinne opened a blank file at nine and started building a new panel: a text box for the pasted thread, a results area for the three proposed times, a loading state, an error state. It felt like the right way to start a build day. By early afternoon she had a screen that looked genuinely good, clean cards, a small check mark animation when a slot came back confirmed.

She ran it twice against threads she'd written herself to sound realistic. Both times it worked. She spent the last hour tightening the spacing on the result cards.

Same eight-hour day, spent two different ways. One buys a polished screen and two tests. The other buys a plain screen and eighteen.

In the review, a director pasted in an actual thread from her own inbox, three people arguing gently about a Thursday that didn't exist because of a public holiday nobody had flagged. The assistant proposed a time on that Thursday anyway. It had never seen a thread with a holiday in it, because Corinne had only ever tested the two she'd written herself.

The review moved on to other things fast. Nobody said the idea was dead. But nobody asked to see it again, either, and the feature didn't make the next quarter's plan.

Corinne got another one-day slot two months later, a different corner of the same idea: propose times from a thread where people are in different time zones. This time, before opening anything, she wrote three numbers on a sticky note. One hour to scope the exact interaction. Two and a half hours to wire it, because Daybook already had a chat drawer built for a different AI feature, a panel that took text in and showed structured results out. She'd drop this into that instead of building new. Whatever was left, she'd spend testing.

Wiring actually took two hours twenty. That left four hours forty for real threads. Fifteen minutes a run, checking the proposed times against the calendars by hand. Eighteen runs by five o'clock, pulled from her own inbox, a coworker's inbox, and a few she asked people to forward on purpose because they looked messy.

Four of the eighteen came back wrong. Two proposed a time across a date-line flip that didn't actually work for the person on the other side. She fixed the date-line handling with forty minutes to spare and reran those four. All four came back clean.

In the next review, the same director pasted in a real thread live, unscripted, the way she had two months earlier. It worked. Not because the screen looked nicer. It didn't, it was still the plain chat drawer. It worked because eighteen real threads had already found its weak spot, and she'd fixed it before anyone else saw it.

The thing I'd tell myself, the morning I opened that first blank file: an empty editor at nine a.m. feels like progress. It isn't, until you know what block of the day it's stealing from.

BOUND, said out loud before you build a single screen

This is a sizing question about how to split a fixed day across scoping, wiring, and testing, not a person's trust flipping between two settings, so BOUND fits and FLIPS doesn't.

B, break it down. The day's hours equal scoping hours, plus wiring hours, plus real-input testing hours, and they have to sum to the day you've actually got. For an eight-hour day, that's the whole equation.
O, own the numbers. One hour to scope the single interaction: propose three times from one messy thread. Two and a half hours to wire it, reusing Daybook's existing chat drawer instead of building a new screen. The remaining four and a half hours go to running it against real threads. One plus two and a half plus four and a half is eight.
U, use a range. That two and a half hours of wiring assumes a reusable shell exists. Without one, building a new panel from nothing runs closer to six hours, which drops testing to about one hour on the same eight-hour day. The range on wiring is two and a half to six hours, and it turns entirely on whether a screen already exists to drop into.
N, nail the sanity check. A real test run, at about fifteen minutes each, means four and a half hours of testing is eighteen runs, and one hour is four runs. A prototype needs at least ten real runs before it's safe to trust in a live room. Eighteen clears that. Four doesn't.
D, direction. The UI-reuse assumption moves the total far more than the target number of test runs does. Losing the reusable shell swings wiring by three and a half hours, which drops testing capacity from eighteen runs to four, the difference between clearing the ten-run bar and missing it badly. Deciding you want twenty runs instead of eighteen only costs another thirty minutes. If the day feels too tight, check for a reusable screen first, before cutting the testing block to hit a target count.

And if you want to be sure it really works, try it somewhere else

A different prototype, a different day: a nonprofit's volunteer platform gets one day to prove an AI feature that reads a shift-coverage request and drafts a message to the three volunteers most likely to say yes, instead of a coordinator guessing who to ask.

B, break it down. Same equation, different day length. The volunteer team can only get a coordinator's time for six hours, not eight, so the blocks are scoping, wiring, and testing hours summing to six.
O, own the numbers. Forty-five minutes to scope: draft one message from one shift request, ranked against the three most likely volunteers. Three hours to wire it, because there's no existing panel to reuse here, the platform has never shown AI-drafted text anywhere, so a small new screen has to get built. That leaves two hours fifteen for testing.
U, use a range. If the coordinator's own shift-history spreadsheet can be read directly instead of re-entered by hand, wiring drops to about two hours, freeing an extra forty-five minutes for testing. If the volunteer-reliability data has to be manually pulled together first, wiring stretches past four hours and testing nearly disappears.
N, nail the sanity check. A real test run here, drafting a message and checking it against a real past shift, takes about ten minutes. Two hours fifteen of testing is thirteen runs. That's under the ten-run floor by a comfortable margin, but tighter than the scheduling assistant's eighteen, worth flagging honestly rather than rounding up.
D, direction. Here it isn't UI reuse that swings the day most, it's whether the reliability data is already in one readable place. That's the lever worth checking before the day starts, the same way the calendar app's answer checked for a reusable screen.

Swap the trigger and it still runs.
Speed: an interviewer caps the answer at ninety seconds. Skip straight to the split: an hour to scope, two and a half to wire by reusing what exists, the rest to test against real input, eighteen runs, well past the ten-run floor.
Cost: instead of one day, a manager offers half a day. Cut wiring first if a shell exists, testing second only as a last resort, since testing is the block that actually tells you anything.
The model got better: a newer model handles time zones and holidays without being told. Wiring doesn't get any faster from that. Testing still needs its own real hours, because a better model still needs to be checked against the specific messy inputs this product will actually see.

Where people run it wrong.
They start building before naming the one interaction, so the day has no shape to protect.
They build a new screen out of habit without checking if one already exists to reuse.
They spend the leftover hour polishing the result instead of running one more real test.

How to use it live. Say the equation before any hour gets named: "the day is scoping hours plus wiring hours plus real-input testing hours, and I'm capping wiring by reusing whatever already exists." That buys the room to actually count instead of guessing a schedule that sounds fast.

Flashcards (click a card to flip it)

Check yourself Score: 0 / 0