Your loading screen is a brand deck

The slowest moment in Vibes DIY is the first one: you type a prompt, and an LLM spends a minute or two writing your app. We work hard to shave that wait — streaming previews, warm shards, precomputed chips — but some of it is irreducible. So the question became: what do you do with a captive minute?

Our answer: play the movie of the brand.

When Jona Bechtolt of YACHT designed the Vibes DIY brand, the deliverable was a brand-brief deck: the capsule logo, a capsule spilling its dots, the squished VIBES letterforms, nine little D·I·Y faces with different hairstyles. Decks like that usually get skimmed once and filed. Ours now plays, in full, as the first-build loading animation.

The PDF's own vectors, not a redraw

The letterforms and motifs on screen aren't approximations of the deck — they are the deck. We extracted the vector paths straight from the PDF with pdftocairo -svg and recolor them per scene. A designer's letterforms carry a lot of personality in their imperfections; redrawing them would have lost exactly the thing worth showing.

Two properties make a slide deck a surprisingly good fit for CSS animation:

• Slides cut, they don't crossfade. That's steps(1) keyframes — the cheapest possible animation, no tweening, no layout work.
• A deck has an ending, but the show shouldn't. The storyboard is paced so the app's first paint cuts it off mid-scene — the timeline is designed "hopefully you never see the end."

And the whole thing is honest about cost: the ~40KB of path data lazy-loads, so the brand moment adds nothing to the prompt→preview critical path it decorates.

Animation before JavaScript

Some of our slowest screens are the ones React can't help with yet — server-rendered HTML waiting for hydration. So the faces flipbook runs there too: the nine hairstyle faces flip on rotation in the SSR output itself, animated by stepped CSS keyframes with zero JavaScript.

That forced one honest engineering decision: the face vectors moved into their own generated module so the route chunk statically carries just the faces, while the rest of the deck stays lazy. The chunk boundary follows when the pixels are needed, not module cohesion.

The loading screen learned semantics

Once the deck was playing, the interesting work turned out to be teaching it to mean things:

• Color means "almost ready." The deck used to give the color D·I·Y face a decorative spin mid-show. Now the black-and-white flipbook holds indefinitely, and the color face appears exactly once: when the build has landed and only the final reveal remains. If you see the rainbow face, your app is seconds away. One scene deleted from a storyboard array, and a decorative beat became progress communication with no text and no state.
• Recovery settles; it never rewinds. When a streamed edit fails to apply and the server regenerates, the deck used to keep rolling — and on long recoveries it would loop back through the whole storyboard, which reads as starting over. Now a recovery jumps the show forward to that same settled face. A loading animation encodes a promise arc, and error recovery should move the arc forward even when the system really is redoing work.
• The status line reads the stream. "Building your app…" became "sending your prompt…" → "planning your app…" → "writing code…" → "adding finishing touches…" — no new state, no new round-trips, just relabeling from signals the client already held.

The wait screen that teaches

The same thinking reached our least glamorous wait: device enrollment in the CLI login flow. It used to be a line of plain text on a localhost callback page. It's now the capsule-spill animation with plain-language captions that narrate what certificate enrollment actually does — two keys, sign the "this is really me" note, and the one idea worth teaching while you wait: your secret key never leaves the device.

A loading screen is captive attention. You can spend it on a spinner, or you can spend it on the one sentence that makes someone trust the thing they're waiting for.