Every product page has a roadmap. Most are wish lists ordered by optimism. This one is a status report: 4 of these bets run in this build, 1 is partly built, and 5 are specifications with no code — because they need a database, a payment path or a second person, and inventing a mock would have made every other number on this site cheaper.
The format for each bet is the same four questions: what exists today, the smallest real slice, what it costs, and the line it must not cross. A bet that cannot answer the last one is not ready.
Live
4
Partly built
1
Spec only
5
01Real accounts & favourites backend
Spec only — no code yet
Today
Favourites, stacks and the admin console run on localStorage and say so on every panel. Nothing is persisted and nothing is sent anywhere.
First real slice
One table, one cookie: `favourites(user_id, asset_slug, created_at)` plus an email-less session. The UI already exists; only the write path changes.
What it costs
A database, a session strategy, a privacy page that mentions storage, and a deletion path. Roughly the first two weeks of a real backend.
What it must refuse
Social sign-in buttons that do not work, and 'sign in with Google' as a decoration. If the button exists, the flow must complete.
The Studio edits every token, previews live and exports CSS, Tailwind config and JSON. It runs entirely in the browser — reload and your theme is gone.
First real slice
Persist named themes to localStorage with export/import, then to the accounts backend when it exists. The save button is the missing product.
What it costs
Storage and conflict handling, plus a paid tier if themes become the flagship — which needs billing, which needs accounts.
What it must refuse
Paywalling the token export that already works today.
GET /api/v1/components/<slug> serves one asset as data: kind, tags, behaviours, stack, dependencies, size, scores, licence, version, published date, props and its changelog version — read from the same record the page renders.
First real slice
Shipped — this one needed no server. Prerendered for all 133 assets, so it is a file read, not a query.
What it costs
A versioned schema and a deprecation policy, which starts the day somebody builds against it.
What it must refuse
Serving a 'code' field that is not the code the demo runs. Until the source is exposed per asset, the API points at the page rather than inventing a snippet.
GET /api/v1/audit returns every asset's automated a11y score, editorial quality score, size and dependency count, plus the banded distribution — the same numbers /quality prints.
First real slice
Shipped. One JSON document, generated at build time from the catalog, so a reader can verify a claim without scraping HTML.
What it costs
A stable field contract and a note pinned to the build id, both of which are cheap once the endpoint exists.
What it must refuse
A score the page and the API could disagree about — both are built from one function.
/embed.js is one file: it finds [data-motif-embed='<slug>'] and replaces the placeholder with the existing /embed/<slug> iframe, at the height the embed reports. No framework, no dependencies, ~1 KB.
First real slice
Shipped. The iframe route already existed; the SDK is the one-tag wrapper around it, and this page runs it live.
What it costs
A versioning policy if the attribute name ever changes — handled by never changing it: new options arrive as new attributes.
What it must refuse
Injecting analytics or a backlink into somebody else's page. The script writes an iframe; nothing else.
Reading paths exist, and progress through them is tracked locally in the browser. There is no account, so there is nothing to certify against.
First real slice
An SVG certificate rendered from locally stored progress, printed with 'self-issued, unverifiable' until a real issuer exists, then replaced by a signed credential.
What it costs
A verification endpoint and an identity — the artwork is the easy half.
What it must refuse
A badge that looks verified when it is self-asserted. The label is part of the design, not a disclaimer bolted on.
The playbook is already public: the quality register, the craft excerpts, the speed story, the open metrics page, the voice guide, the launch checklist and the build notes are all on the site, with the numbers they cite.
First real slice
Shipped as the site itself — and the one addition an open book deserves is a weekly measurement series, which is listed as still open on the launch page.
What it costs
Discipline: every new claim has to keep pointing at a surface that can be checked.
What it must refuse
Turning the playbook into a lead magnet. The moment it needs an email, it stops being an open book.
The three APIs and the open book needed no server, so they are real: a per-component JSON document, an audit document, a one-file embed SDK, and the site's own playbook published with its numbers. Marking them “planned” when they were an afternoon's work would have been the easier and less honest option — and it would have hidden the fact that the other six genuinely need infrastructure this repository does not have.
When a spec becomes real, this page changes its chip and the ledger gets a row. Until then the chip is the deliverable.