Analyze how a consumer AI app handles the cold start problem.

Humlet suggests a recipe based on what's in your kitchen and how much time you have. Dagny Solheim runs a small-town veterinary clinic all day and opens the app most nights around 11, once the clinic's closed and she's finally thinking about dinner.

How to answer this, stage by stage

Six moves. This is a design question: the interviewer wants your one concrete anchor decision, not a tour of every screen.

Let's learn

Every night for six years, once the clinic's last patient went home, Dagny made one of the same three dinners, mostly because deciding anything new felt like one more thing to figure out.

Humlet is a consumer app that recommends a recipe based on what you actually have and how much time you've got that night.

Without an app, this was Dagny's actual routine: too tired to plan, she'd default to whatever required the least thought, usually pasta, usually the same jar of sauce.

At its worst: a new user opens the app once, sees a list that could belong to anyone, closes it without cooking a thing, and never opens it again. That's a cold start failure with no error message, just a quiet non-return.

What I would leave alone: a full flavor-preference quiz, or a complete pantry scan, can wait entirely until later sessions. Day one doesn't need deep personalization. It needs to not feel like it was built for a stranger.

The lesson: a generic first list isn't a placeholder while the app "learns" someone. It's a real first impression, and it's making one whether anyone designed it on purpose or not.

Now here is the same thing as a story

The short version above is what you'd say defending this design live. Read this one for how Dagny's actual first night with the app went.

Most nights, once the clinic closed, Dagny's routine was the same: feed the cat, sit down, and reach for whatever needed the least amount of deciding.

Four steps, and the second one, a list that could belong to anyone, is where a generic cold start actually loses a new user.

The first version of Humlet she tried opened straight to a top-10 popular recipes list. Nothing in it reflected that she was cooking for one, had about twenty minutes, and had a container of leftover rice she needed to use before it went bad.

The entire redesign is the difference between these two panels: one question, asked before anything else.

She closed the app after scrolling twice, cooked pasta again, and didn't open it for another week.

The very first recipe shown sits in the riskiest, most common corner. It's exactly where a generic guess does the most damage.

A later version asked one question the moment she opened the app for the first time: what did she have too much of, right now. She typed "rice," and the very first recommendation was a fried rice recipe built around exactly that, ready in fifteen minutes.

Two wrong assumptions, and one small question that quietly fixes both of them at once.

She actually cooked it. Not because the recipe was extraordinary, but because for the first time, the app felt like it had been paying attention, on day one, with zero history behind it.

Someone building the original version decided a generic popular-recipes list was the safe, obvious default for a brand-new user, since there was no data yet to personalize anything. That's a reasonable starting assumption, and it's also exactly where the design stopped, treating "no data yet" as a wall instead of a five-second question away from not being true.

I would take that assumption back and build the one-question start instead, cheap to ask, answerable in seconds, and enough to make day one feel specific rather than generic.

We shipped the generic list first because it was the fastest thing to build with zero user data, and it felt like the responsible, safe choice. It took watching real new users open the app once and quietly never come back, with no complaint, no review, nothing but a silence in the retention numbers, to see that "safe" and "actually working" weren't the same thing.

SPARK, in one screenFive letters, and the anchor, one quick question before any recommendation, is the whole design.

The recap, one line per letter: situation is the existing habit of falling back to the same three meals, payoff is trusting a new suggestion instead, anchor is the one-question start, risk is the one-tap swap for a wrong first guess, and keep out is deferring deep personalization past day one.

And if you want to be sure it really works, try it somewhere elseSame five letters, a volunteer-matching app instead of a dinner app. This time the cold start question is about a skill, not a fridge.

A regional volunteer-matching nonprofit built an app that suggests local volunteer opportunities. A brand-new user, with zero history, would otherwise see the same generic "popular this week" list every other city sees.

Mapped onto SPARK: situation is someone who wants to help but has never volunteered through an app before, and would otherwise just not bother searching at all. Payoff is turning a vague, well-meaning intention into an actual first sign-up within the same week. Anchor is one quick question at first launch: "what's one thing you're actually good at?" instead of just asking for a city and a generic interest category. Risk: if the first match still misses, an "this isn't really my thing" tap asks one more quick question about time availability instead of dumping the user back into the full unsorted list. Keep out: a full skills-and-availability intake form, the kind most volunteer platforms front-load, waits until after that very first match, since asking for too much up front is its own way of losing someone before they ever see a single opportunity.

A different app, a different question, and the same underlying anchor: ask one small thing before showing anyone a generic list.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "ask one real question before the first recommendation, instead of showing every new user the same generic list" and stop.
Cost: no engineering time to build a smart first-question flow this quarter. Say so, and start with the cheapest version: a single multiple-choice question with three or four options, not free text, still personalizes the first list without much build cost.
The model gets better, for real: even if Humlet's underlying recommendation model improves substantially, a generic top-10 list still ignores the one piece of information that actually mattered, what this person has and needs tonight. A better model doesn't fix a missing question.

Where people run it wrong.
They treat the cold start problem as something only more data or a better model can fix, instead of a design decision about what to ask on day one.
They build a long onboarding quiz, assuming more questions means more personalization, when a single well-chosen question usually beats ten generic ones.
They forget to design for the moment the first guess is wrong, leaving new users with no way forward except closing the app.

How to use it live. When asked how a consumer app handles cold start, ask yourself one question first: what's the single cheapest thing you could ask a brand-new user that would meaningfully change what they see first? That question is almost always the real answer, not a list of personalization features.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0