Build spec
A café owner answers eight either/or questions on your website and watches their own ordering app take shape as they tap. Thirteen taps worst case, eleven on a smooth run. This spec covers the question sequence, the progress and celebration mechanics, and where an AI model does and doesn't belong.
The two headline findings
The funnel needs no AI at runtime. Eight binary questions produce an 8-bit answer — that's a lookup table, not an inference problem. A model in that path buys non-determinism, a network dependency and a failure mode in exchange for nothing, and costs you the ability to answer "why did my app come out green?" A model earns its keep after the last tap: parsing their menu, and writing the copy in their voice.
Progress bars correlate with lower completion in the wild — the largest study here (25,080 real surveys) found exactly that. It doesn't mean drop the countdown you asked for; it means build it the specific way that works — discrete steps, endowed with a head start, counting down — and measure it rather than trusting it.
Architecture
Claude Sonnet 5, not Opus 5 — and the reason isn't benchmarks. At this volume the entire monthly spread between the cheapest and most expensive credible option is under A$60, so this is not a cost decision. It's an integration decision: you already build with Claude, and one provider means one key, one SDK, one billing line, one place to debug. Opus 5 is real money for no gain on copywriting; Haiku's smaller context is the one thing in the lineup that could choke on a long PDF menu.
One exception worth testing. Menu parsing is the highest-value model task — it replaces 45–90 minutes of typing per client, and it's the difference between a A$1,000 build being profitable. It's also the one place the evidence points away from Anthropic: Google's models lead document-parsing benchmarks at roughly a third the cost. But none of those benchmarks test café menus, where the hard part isn't reading the text — it's interpreting size tiers, modifier groups and "+50¢ oat". Run a bake-off on 20 real messy menus (angled phone photos, a chalkboard, a two-column PDF, one handwritten), scored on items, prices and modifiers correct. If Gemini wins clearly, use it for menu parsing only — it's one bounded function.
Don't self-host (break-even is ~400× your volume), don't adopt a model gateway (~100× your spend), and never run client menus through a free tier that may train on them.
The sequence
Six show two rendered phone screens; two are text, because tone doesn't photograph. Every question varies exactly one attribute and holds everything else identical — the most common failure in visual quizzes is a pair that differs in three ways at once, so the tap tells you nothing about which one drove it.
Order runs easiest and most enjoyable first, most committing last. The largest study of survey completion found that the first question's type predicts whether people finish, so the opener is a pure image tap — never a text field, never a name.
Mechanics
The finding that shapes the design
Across 25,080 real web surveys, the ones without progress bars had higher completion than the ones with. A separate controlled study found the mechanism: it's not the presence of progress, it's the rate — early feedback showing slow progress increases abandonment, while intermittent feedback tested best of all.
So the countdown you asked for stays, but built the specific way that survives this: discrete dots, not a creeping percentage (at 10 steps each tap is a visible chunk; a bar crawling 0→10% is precisely the failure mode), endowed with 2 filled so question one lands at 30% rather than 10%, and counting down because "5 to go" is concrete where "50% complete" is abstract. Then instrument it and A/B it against a plain "3 of 8" — the evidence is strong enough to design around but not strong enough to trust blind.
Three, all inline and zero-tap. None gets its own screen or a Continue button — three interstitials would eat 20% of the tap budget outright.
Every one says what the answer did: "Warm and rustic — that's most of the hard part decided." Never "Great job!" — congratulating a business owner for tapping a picture reads as contempt.
The best celebration isn't a celebration: the mockup visibly re-rendering in their choices after every tap. Intrinsic payoff, no praise, no tap.
1 start · 8 questions · 4 for details and submit = 13 worst case
Eleven on a smooth run, because the phone keyboard's Next key moves between fields without taps. That leaves two in reserve for a back-tap and the result-page call to action.
Three rules hold it together: auto-advance on tap (no Next button on question screens), zero-tap celebrations, and one details screen — never split contact fields across pages.
Both option cards stack full-width in the lower two-thirds of the screen — roughly half of phone use is one-handed with a thumb, and the top corners are the worst real estate available. Never side by side on a phone: three-across or side-by-side shrinks the images, and shrunken images defeat a visual-preference question entirely. No scrolling on any question screen. Auto-advance with a 350–450ms transition, long enough to see the mockup update and short enough not to drag.
Alt text describes the difference, not the position — "Ordering screen in warm terracotta and cream", never "Option A". Announce progress in a polite live region ("Answered. Five questions to go.") and move focus to the new question heading on auto-advance, or keyboard and screen-reader users are stranded mid-funnel. Wrap the confetti in prefers-reduced-motion: no-preference and swap an instant static state change underneath — and note the popular confetti library animates regardless unless you gate it yourself.
Give every pair a low-emphasis "not fussed" link. Forced binaries with no escape produce irritation and random data, and one tap either way keeps the budget intact.
What kills it
| Mistake | Why it's fatal |
|---|---|
| Celebration screens with a Continue button | Three of them consume a fifth of the entire tap budget. Inline only, always. |
| Pairs that differ in three ways at once | If A is dark and serif and photo-led, the tap tells you nothing. Vary one attribute; hold the rest identical. Otherwise the "design" is theatre. |
| Asking about taste in words | "Modern or rustic?" — nearly everyone says modern, and the words map to different pictures in different heads. Show rendered screens. |
| Over-promising the count | If it says "3 to go" it must be exactly 3. Under-promising is safe; over-promising is a documented abandonment driver. |
| A canned result | Eight questions must not collapse into one of four templates. If the reveal isn't visibly bespoke, the funnel is exposed as a lead-capture costume — and your credibility with a small-business owner is the actual product. |
| Pairs too similar to tell apart | If the difference isn't visible in about a second, on a phone, at arm's length, the answer is noise. Exaggerate the contrast beyond what you'd ship. |
| Email gate before the reveal | You lose people at the worst possible moment — after they've done all the work. Show the design, then ask where to send the working link. |
| Required phone number | The highest-friction field on any form. This audience will give it to you on the call anyway. |
| Stock photos of cafés | Abstract and lifestyle imagery measurably fails at this job. Show the product — a phone mockup of the actual ordering screen. |
| Assets loading mid-quiz | A spinner at question four is the slow-progress failure mode by another route. Preload everything on the start screen. |
Decisions still open
Prepared August 2026 for The Creative Bridge (Adelaide, SA). Evidence grades in the underlying research separate peer-reviewed findings from vendor marketing; where a claim is vendor-sourced it is marked as directional in the source notes. Companion documents: the agent-run research brief, and the live demo at demo.lotushosting.org.