About

A website built to be taken apart

This is not a product. It is a place to build one capability at a time — properly, with the reasoning written down — so that the knowledge transfers to real work afterwards.

Most learning projects fail in the same way. You follow a tutorial, the app works, and you are left unable to say which parts you understood and which parts you copied. The gap only shows up later, when something breaks and none of it is familiar.

So this project inverts the usual arrangement. Instead of one application that happens to use several technologies, it is a deliberate inventory of capabilities — each one recorded with the technology behind it, an honest status, and a note on the transferable idea it demonstrates. The smallest are isolated as Lab experiments; the larger ones ship as real sections of the site — shop, forum, newsletter, organizations — which is what makes them worth forking.

The constraint that keeps it honest is that a capability carries three separate facts: whether it is built, whether its provider is configured, and whether anyone has watched the real path succeed in production. Code that has never run against a real provider is Ready, not Live, and the remaining work is impossible to lose track of.

Growth is incremental by design. The Lab framework means a new experiment costs a component, a registry entry, and one line in the loader map — never a routing change or a refactor. That is the property that lets a sandbox keep accepting new ideas instead of calcifying after the third one.

Project shape

Where things live and why they live there.

src/app

Routes, layouts, and API endpoints. The folder structure is the URL structure.

src/components/ui

Design-system primitives — button, card, dialog, input. No business logic.

src/components/layout

Header, footer, theme provider, shared page chrome.

src/experiments

One folder per Lab experiment, plus the registry that indexes them.

src/lib

Server-side logic by domain: the database client, auth, mail, storage, commerce. Each domain keeps its pure rules in a rules.ts a unit test can import.

src/app/api

Route Handlers, for whatever a browser or a third party must call by URL: webhooks, presign, the chat stream, the public API.

docs

Architecture notes, the capability inventory, and the development log.

Working principles

Label reality, not intent

A screen that looks finished and a screen that is finished are different things. Every capability carries a status, and generated data is always marked simulated — never active.

Small, reviewable steps

Each phase adds one coherent slice and leaves the application runnable. No big-bang rewrites, because you cannot learn anything from a change you cannot read.

Secure by default, not by memo

Secrets stay server-side, input is validated at the boundary, and known weaknesses are written down on the Stack page rather than quietly hoped over.

Own the important code

Dependencies earn their place. Radix is here because accessible focus management is genuinely hard; the components wrapping it live in this repo where they can be read and changed.

The roadmap is part of the product

Planned capabilities are listed inside the app rather than hidden in a backlog, so the distance between what exists and what is intended stays visible from any page.

See the inventory Browse the Lab