Product UI · SaaS Shells

Two shells. Pick one per product.

Every LMV product that needs an app, not an article, starts from one of two reusable dark-shell skeletons. Both were lifted out of real apps we already ship. You do not merge them. You look at the product, pick the one that fits, and build inside it. Same navy rail, same warm tokens, same grammar as the rest of this book, just turned toward software instead of newsprint.

§ 1

Two reusable shells. Ship both, pick one per product.

Not a merge · Both billing-agnostic

We extracted two SaaS shells from two real LMV apps. The whole point is that they stay separate. You ship both into the toolkit and pick the one that fits the product you are building. A record-centric app gets the fly-out. A net-new product that wants the strongest foundation gets the primitive library. Trying to fuse them into one mega-shell is how you end up with a skeleton nobody wants to reuse.

Option A · Fly-out

The summary-to-detail move.

An 88px navy rail and a list of records. Click a row and a rich detail drawer flies in from the right edge while the list stays put. Built for products where people live in a list-then-detail loop.

Option B · Primitives

The strongest foundation.

An 86px navy rail, a Cmd/Ctrl-K command palette, a full typed primitive library, and an auth seam that degrades to demo mode with no keys. Built for starting a new product on solid ground.

Same bones as the rest of the system. Both shells run on the LMV dark-shell tokens: navy #123260, rust #c24c32, gold #e6bf4a, warm-white #fffaf0. Inter-led UI, Fraunces for headers, JetBrains Mono for meta. Sharp corners, no pills, no gradients, styled scrollbars. The token set was reconciled to one canonical layer during extraction, so there is no drift between the two.

Navy · #123260 Rust · #c24c32 Gold · #e6bf4a Warm-white · #fffaf0

§ 2

A vs B

Source · Signature move · When to pick

Read this top to bottom, decide once, then commit. The two shells share an anatomy but answer different questions. A is for products that already know their records. B is for products that are still finding their shape and want the richest starting kit.

Dimension

Option A

Fly-out

Option B

Primitives

File

shell-a-flyout.html

shell-b-primitives.html

Source

Extracted from lightbreak-v2. The chrome and the Issues review screen, lifted straight out of the live app.

Extracted from coaching-os. The app shell, the lmc-* primitive layer, and the command palette, lifted straight out of the live app.

Signature move

OverlayDrawer. Click a summary row and a rich detail panel flies in from the right alongside the 88px rail, with a scrim, Esc to close, and a close X. The system's compress-to-summary, expand-to-detail pattern.

Command palette + primitives. A Cmd/Ctrl-K palette over a clean typed library: buttons, inputs, select, switch, card, badges, tabs, segmented control, progress, empty states, plus a demo-mode auth seam.

Rail

88px navy icon rail · brand, nav, settings, avatar.

86px navy icon rail · same anatomy.

Master / detail

List, then a right-side fly-out drawer that overlays without losing the list context.

Routed master / detail plus a fixed right-hand context panel, the AI co-pilot column.

Pick it when

The product is record-centric, issues, deals, tickets, contacts, and people live in a list-then-detail loop. The fly-out keeps context while showing depth.

You are starting a new product and want the strongest foundation: a finished primitive layer, a command palette, and an auth seam that degrades to demo mode with no keys.

Billing

None. Billing-agnostic on purpose.

§ 3

Option A · Fly-out

From lightbreak-v2 · Record-centric

Shell A

A live preview of the fly-out shell. The screen is an Issues list. Click any row and watch the detail drawer fly in from the right while the list holds its place. That single move is the whole reason this shell exists.

Option A · Fly-out shell · live preview Open standalone →

Try it Click an Issues row in the list above. A rich detail drawer flies in from the right edge alongside the navy rail. Press Esc or the close X to send it back. The list never loses its place.

§ 4

Option B · Primitives

From coaching-os · Strongest foundation

Shell B

A live preview of the primitives shell. Same navy rail, but the value is the command palette and the full typed primitive library underneath it. Hit the keyboard shortcut to summon the palette, then browse the components it ships with.

Option B · Primitives shell · live preview Open standalone →

Try it Click into the preview, then press Cmd / Ctrl + K to open the command palette. Scroll the primitive library below it: buttons, inputs, select, switch, card, badges, tabs, segmented, progress, and empty states. Auth runs in demo mode, no keys needed.

§ 5

Billing is a future add-on module

Kept out on purpose

Neither shell ships a plan, upgrade, or pricing screen, and that is deliberate. Billing is a future add-on module that bolts on when a product needs it. Kept out, the shell stays a clean, reusable skeleton you can sell or drop into the next product without ripping payment logic back out. Add the money layer when the product earns it, not before.

What the shell is

A clean reusable skeleton

Billing-agnostic by designNo plan, upgrade, or pricing UI baked into either shell.
One canonical token setNavy, rust, gold, warm-white, reconciled across both shells with no drift.
Drop-in starting pointPick one, build the product inside it, keep the LMV grammar for free.

What it is not

Not a finished product

Not a merge of A and BYou pick one per product. Fusing them defeats the reuse.
No payment logic to rip outBilling arrives later as a module, never wired into the skeleton.
Not the place for pricing pagesThe money layer is a separate, opt-in surface added when earned.