Tear down the onboarding of an AI product you use and identify its weakest moment.

Tallyhatch connects to your bank account, pulls transactions, and sorts them into a monthly budget with no manual entry needed. Ines Cabral runs a small bakery alone and signed up on a Tuesday night, an hour after closing, to finally stop doing her books on paper.

How to answer this, stage by stage

Nobody's grading whether you picked the "right" app. They're grading whether you can find the one moment that actually breaks trust and say why.

Let's learn

Say we build a budgeting app that reads a bank feed and drafts a small business's monthly numbers with no manual entry required.

Tallyhatch is that app. Sign up, link your bank, and within a few minutes it hands you a categorized budget, no spreadsheet touched.

For the roughly 4 in 5 new users whose bank connects cleanly, onboarding is genuinely great: a working budget appears in minutes, and they stay.

Then there's the other fifth. At its worst: a bank link fails, the screen offers nothing but "try again," and a new user who was ready to trust the product entirely just closes the tab.

What I would leave alone: the email verification step. It's a small extra tap, mildly annoying, but nobody abandons a budgeting app over one verification email. Fixing it wouldn't move the number that actually matters.

The lesson: a product that promises full automation, with nothing built for the moment automation fails, isn't offering convenience. It's offering a coin flip, and only telling the winners about it.

Now here is the same thing as a story

The short version above is what you'd say defending this teardown live. Read this one for how it actually played out over eight days.

Every night after closing, Ines Cabral used to sit at the counter with a paper ledger and a calculator, entering the day's ingredient costs and sales by hand. She'd run the bakery alone for three years and could eyeball her margin on a batch of croissants before the calculator finished.

Five stops, and the third one, the flip, is the one that decides whether this whole teardown has any teeth.

She signed up for Tallyhatch on a Tuesday night, an hour after closing, hoping to finally retire the paper ledger. The sign-up took two minutes. She linked her bank the same night, and it worked on the first try.

Nothing dramatic happens on day eight. The real event already happened on day two, and day eight is just where it finally shows up as churn.

By day two she'd stopped reaching for the paper ledger entirely. The first sync had been clean, categorized correctly, and honestly a little magical. So when a second bank account she added, one she used for a small wholesale side line, failed to connect, she had nothing left to fall back on.

Two rejected options sit next to the real fix. Email support is too slow for a nightly habit. Silent auto-retry hides the problem instead of solving it.

The screen just said "we couldn't connect to this account, try again." No manual option. No explanation. No sense of whether this was rare or common.

One extra box on the screen, a place to type the numbers in by hand, is the entire difference between these two panels.

She opened the app once more, two days later, mostly out of habit, saw the same message, and closed it. By day eight she hadn't opened it again. Her paper ledger, half-abandoned, sat under the counter, and she went back to it without ever filing a complaint or leaving a review.

Bank link failure is the only moment sitting in the dangerous corner: it happens often enough to matter, and it feels severe enough to end the relationship.

Nobody at Tallyhatch decided to abandon their unsupported-bank users. Somebody decided, back when the product first launched, that the onboarding copy should sound confident and simple: "connect your bank and we'll handle the rest." At the time, the handful of early testers all banked with institutions the middleman service supported perfectly. The line was true for everyone who'd ever read it.

It stopped being true the moment real small-business owners, using every kind of local, regional, and community bank, started signing up. Nobody rewrote the line, because nobody was watching the users it was now failing.

With a manual entry fallback sitting right there the moment the link failed, Ines fills in a week of transactions from memory and her register tape in about ten minutes, on the exact same Tuesday night. She comes back the next evening to check the budget it drew up, and the paper ledger stays retired for good.

I wrote "we'll handle the rest" because it sounded confident in a pitch deck, and nobody had pushed back on it yet. It took watching a real bakery owner quietly go back to paper, with no complaint and no way for us to even see it happen, to understand that a promise with no fallback isn't confidence. It's a bet we were making with her trust.

If you want to remember it easily, here is another way

F, find the person → Ines Cabral, sole proprietor, does her books alone after closing.
L, locate the habit → She retired her paper ledger within two days of one clean bank sync.
I, identify the flip → She didn't complain or retry harder. She quietly stopped opening the app for good.
P, pinpoint the old decision → Onboarding copy promised full automation with no fallback for the banks that don't link cleanly.
S, show the replay → With manual entry offered on the spot, she's back to checking her budget the very next night.

And if you want to be sure it really works, try it somewhere elseSame five letters, a different flip family: a fitness app instead of a budgeting app, and this time the person over-trusts instead of abandoning.

Formhold is a consumer fitness app that uses a phone camera to auto-detect the weight plates on a barbell and log a workout without any manual entry. A new user's first session goes smoothly: the camera reads the plates correctly, logs three sets, and the whole thing feels effortless.

Mapped onto FLIPS, with a different flip: F is a new gym member starting a strength program alone for the first time. L is that she stops double-checking the logged weight against what she actually loaded, since the first several reads were correct. I is the over-trust flip, not abandonment this time: the camera misreads a plate once, silently, and logs a weight 20 pounds lighter than what she actually lifted, and she never notices because she'd stopped checking. P is the onboarding decision to never show a "does this look right?" confirmation on the very first few logged sets, since testers found it annoying. S is the replay: with a lightweight confirm step for just the first five sessions, the misread gets caught the moment it happens, not weeks later when her program is quietly built on wrong numbers.

A different product, a different flip, and yet the missing piece rhymes: no visible way to catch or correct what the camera got wrong.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "the weakest moment is the bank-link dead end, not the sign-up screen, because that's the one failure with zero fallback" and stop.
Cost: no engineering time to build manual entry this quarter. Say so, and start with a single honest sentence on the failure screen naming that manual entry is coming, so at least the user knows it isn't a dead end forever.
The model gets better, for real: even if the bank-link success rate climbs from 84 percent to 95 percent, the users hitting that remaining 5 percent still get the exact same dead end. A better success rate doesn't fix a missing fallback, it just makes the gap smaller and easier to ignore.

Where people run it wrong.
They tear down the sign-up form and the first-screen copy, the parts they can see easily, and miss the one moment where a real technical failure meets zero fallback.
They measure onboarding completion as one overall number instead of splitting it by whether the core automation actually worked.
They assume a quiet drop-off means the product wasn't good enough, instead of checking whether it simply had no second option when the first one failed.

How to use it live. When asked to tear down an onboarding flow, ask yourself one question before touching a single screenshot: where does this product's core promise have a real chance of technically failing, and what happens the instant it does? That's almost always the weakest moment, not the prettiest or ugliest screen.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0