The question: when a user builds one of the apps people actually make — a landing page, a dashboard, a Spotify clone — what does Build's design default to, and how good is it on a phone? What we did: generated the 10 most popular vibe-coder genres from terse prompts, rendered each on a real device viewport, and audited the design mobile-first. The finding:
Per app the craft is real. Across apps it converges on the same grayscale dashboard — and the style-choice step never appeared, so users get the default whether it fits the genre or not. On a phone the gaps show: 1 of 10 apps handles the dynamic viewport; the landing page overflows; text shrinks below 12px.
The fix: teach Build to detect the app's genre and offer ~5 themes that fit it — never one default — on a correctness floor that handles mobile. Both ship below as paste-able system instructions.
A capable layout engine — that skips the phone.
10 genres rendered on a real 390px phone; the static code audit spans all 13 generated apps (per-dimension N noted where smaller). The mechanics are competent; the design system and mobile are where it falls.
dvh); 11× fixed h-screentext-[7px])| Dimension | Grade | Lever |
|---|---|---|
| Spacing scale | A− | — |
| Edge / empty states | B+ | instruction |
| Visual hierarchy | B | instruction |
| Layout rigor | B− | instruction |
| CTA clarity | B− | instruction |
| Signal-to-noise | B− | instruction |
| Color system | C | template-tokens |
| Radius discipline | C | instruction |
| Genre-appropriateness | C | style-system |
| Responsive composition | C | instruction |
| CLS / viewport | C+ | instruction |
| Type scale | D+ | template-tokens |
| Elevation system | D | template-tokens |
| Typography tokens | D | template-tokens |
| Measure / readability | D | template-tokens |
| Component / token reuse | D | template-tokens |
| Identity / distinctiveness | D+ | style-system |
The mechanics grade B-ish; the design-system dimensions grade C/D; the lowest is Identity. The fix routes to three levers: instruction (correctness — next section), template-tokens (a shipped theme file), and style-system (a chosen aesthetic — the palette below). Build can diverge — proof it's default-gravity, not a ceiling.
The floor every app should clear — independent of style.
Deliverable 1 of 2 — the correctness floor: a system-instruction block that fixes the taste-independent problems above — overflow, off-canvas clipping, mobile, ergonomics. The genre router (deliverable 2) sits on top of this; style never overrides correctness.
md:. Zero horizontal scroll at 390px.dvh/svh, never vh (iOS URL bar).text-xs.Style is conditional on the app — each gets ~5 fitting options.
Every card opens on Build's real output (“As generated”), then offers the ~5 styles this app's genre should pick from — the same genre→style routing the instruction encodes. Each is a clean token swap at the app's own polarity. Tap a chip to re-style that app.
Detect the app type → suggest fitting styles.
Deliverable 2 of 2 — the genre router (the headline): Build should infer the app's genre and offer the user ~5 styles that fit it — never one generic default. This is the exact genre→style routing the gallery above demonstrates. Below it: the 10 styles' palette + each one's paste-able @theme instruction.
This is what ships to the team: a paste-able directive block + a Tailwind v4 @theme token set, per style. Pick a theme to read its instruction.
Full text: design/instructions-genre-styles.md (genre detection + routing), design/instructions-styles.md (the 10 token sets, light & dark), design/instructions-default-fix.md (the correctness floor).