I've watched three different people mishandle the same thirty-second screen — the plan card that shows up between your prompt and the build — and each one paid for it in a different currency. One paid in a rebuild. One paid in wasted typing. One paid in a product that couldn't do the thing they actually needed. The plan card is the cheapest moment in the whole process to change your mind, and somehow that's exactly what makes it easy to blow past.
Mistake one: rubber-stamping it
This is the common one. Skeleton looks right, hit approve, move on — I did this for weeks before it bit me. The build that finally broke the habit came back with a Stripe checkout wired into a static site that had nowhere to put the account state Stripe needed. The plan had said product type: static site in plain text, right there on the card, and I scrolled past it because the page list looked fine and I was in a hurry.
The wreckage from this mistake is always the same shape: everything downstream of the plan is correct given the plan, so the failure doesn't surface as an error, it surfaces as a working build that's structurally wrong. Nobody flags it because nothing's broken — a static site with a checkout button just does the wrong thing silently, or fails at the one moment a real user hits "pay." You find out in review, which is the most expensive place to find out.
Mistake two: over-specifying to avoid a second round
The opposite failure looks more responsible and isn't. Some people, once burned by mistake one, overcorrect into writing a paragraph of precise requirements at the plan stage — exact copy, spacing preferences, which features definitely should and shouldn't exist, phrased like a spec document. I've done this too, out of a vague anxiety that skipping detail now means "wasting" a build round later.
It's backwards, and here's why: the plan is going to get revised again once you see the actual pages, regardless of how careful you were the first time. And when it does get revised, you're not getting a diff of what changed — you get a fresh card that already incorporates your edit, full stop, no patch notes. So the precision you typed at round one doesn't survive intact into round two anyway; you're re-reading the whole thing either way. Two or three rounds of "no, like this" gets you to a better result, faster in wall-clock time, than one exhaustive brief — even though writing the brief feels more efficient while you're doing it.
The plain-language edits that actually work are short:
- "Drop the blog, add a pricing page" — swaps the page list cleanly.
- "Make it two-player instead of single-player" — bigger than it sounds. It can touch the data model, now tracking two participants instead of one, and the revised plan will show that ripple rather than hide it.
- "This needs user accounts" — if the current plan is a static site, this is the sentence that forces the product-type question outright.
Mistake three: treating product type as a soft field
This is the expensive one, and it's expensive because everything else on the card is genuinely recoverable. Pages, inferred features, most question-forks — all fixable with a version iteration after the build lands. Product type isn't. There are four buckets:
| Product type | What it means |
|---|---|
| Static site | Plain, no server logic. |
| Installable app | PWA-style — offline-capable, addable to a home screen, still no server logic. |
| Framework build | React/Next-style, heavier client interactivity, still no persistent backend. |
| Server-backed app | The only one of the four with a real database and account system behind it. |
Approve a static-site plan, decide three versions later you want login, and that's not a version bump — it's a rebuild from a different product type, and you lose the continuity the version history gave you for everything else.
People get this wrong two ways. First, they don't check their own prompt against the field — if your prompt has "accounts," "login," "save," "dashboard that updates," "payments," or "multiple users editing the same thing," and the card doesn't say server-backed, that's the one edit worth making before you approve, no exceptions. Second, they confuse installable app with framework build, because both feel like "an app" in casual conversation. They're not interchangeable: installable app fits a tool where all the state lives on the user's device — a tip calculator, a workout timer. Framework build means more interactivity and component structure but still nothing persisting server-side across sessions or devices. Neither one is "an app" in the sense of having accounts and data that follows you across devices — only server-backed is. And over-provisioning to server-backed "just in case" for a portfolio site or a documentation page isn't the safe choice either; downgrading later is just as much of a rebuild as upgrading would have been.
What's left once you stop doing those three things
Once you're not skimming past the product-type line, not writing a spec at plan stage, and not treating account/data/payment language in your own prompt as negotiable, what's left is a fast, narrow check:
- Read the product type.
- Cross-check it against your prompt.
- Skim the inferred-features list for anything you'd reject on sight.
The list exists precisely because a prompt like "scheduling tool for hair salons" pulls in things you didn't type — calendar view and SMS reminders and a client list, some of which you meant and some of which is scope creep the model added because those features statistically travel together. Prune what doesn't belong in a sentence, here, instead of after it's built.
Everything else — copy, spacing, which shade of accent color, whether the button says "Get Started" or "Try It Free" — isn't on the card at all, deliberately. Those are cheap to see and fix on a working build, so the card doesn't waste your attention on them, and neither should you. That's maybe fifteen seconds of real judgment inside the thirty seconds it takes to read the thing.
