𝕏Message
Michael profile

Variants in the tree

You build the Problem slide three different ways before you find the one that works. The first is a stack diagram. The second is "Monday morning" — a narrative of one user's day. The third is three blunt sentences. You ship the third.

In most workflows, the first two are gone. They lived in a Figma frame you closed, or a branch you didn't merge, or an old screenshot in a Slack thread. When the next investor asks for the deck and the third version doesn't land, you can't get the others back without rebuilding them.

The directory pattern

In a deck-as-code repo, you keep them all.

slides/
  problem-slide.tsx                       # current canonical
  problem-variants/
    into-brain.tsx
    into-brain.notes.md
    monday-morning.tsx
    stack-diagram.tsx
    three-truths.tsx
    options.notes.md

problem-slide.tsx re-exports the variant currently in use:

export { ProblemSlide } from "./problem-variants/three-truths"

The other variants stay in the tree. They're real components. They build. They render. They're one import-rename away from being the live slide again.

What options.notes.md is for

A small markdown file in the variants directory recording the trade-off:

into-brain — strongest visual, but the metaphor needs explanation. Use for warm rooms.
monday-morning — best for non-technical audiences. Slow start; loses cold rooms.
stack-diagram — most "founder credibility." Wonky for generalists.
three-truths — current default. Fastest land. Loses some emotional weight.

This is the kind of context that disappears the moment you delete a Figma frame. In the source, it stays.

The cheapest A/B test in a pitch

Tuesday morning, you've got a pitch with someone whose background is more design than business. The default Problem slide is the three-truths one — direct, blunt, fast. For this audience the Monday-morning variant probably lands better.

// problem-slide.tsx
export { ProblemSlide } from "./problem-variants/monday-morning"

Commit. Push. Tuesday's deck is tailored. Wednesday morning you swap it back. The other variant didn't go anywhere — it's still in the tree.

You did not rebuild a slide. You did not duplicate a deck. You changed one import.

Why this beats branches

Branches are great for code that should never coexist. Variants of a slide are code that should always coexist. They're not rival implementations — they're a kit. You don't want to switch branches to try a different variant. You want to point.

Putting them in the tree as siblings is the right shape. It says: these are valid alternatives. Pick one for now. The others are kept hot.

Why this beats design tools

Figma is great for designing. It is bad for shipping, because the design has to leave Figma to become real. Once it's left, the Figma frame goes stale. Six months later the Figma version and the real version don't match.

If the variant is React, the variant is the real thing. There is no "design version" and "shipped version." The design is the source. The variant in the tree is what got rendered last time you mounted it.

When to graduate or delete

A variants folder grows. Eventually some variants are clearly dead — they lost an audience test, the metaphor broke, the data they relied on is gone. Delete them. The point isn't to hoard. The point is to keep the live alternatives easy to swap.

A good rule: if you wouldn't show a variant in a real pitch in the next month, delete it. If you would, it stays.

What it costs

A few directories. A few extra files. Slightly more discipline about which variant is the canonical one (the re-export pattern fixes most of that).

What you get is a deck where you stop being afraid of trying a layout. The cost of trying isn't "rebuild the slide if it doesn't work" — it's "save it next to the others." Iteration becomes additive instead of replacive.

In nopoint, every slide can have a <id>-variants/ folder. The framework doesn't care. The tree is the kit.