The site you are reading is the product. There is one repository, nothing is generated out of it, and the storefront, the docs, the checkout and the dashboard are all running code you now own.
That has one consequence worth knowing before you start: every decision here is yours to overturn. docs/adr/ records why each one was made, including the options that were rejected, so you can tell a considered choice from an accident. Supersede them; do not obey them.
What is wired together
Identity is Clerk. Billing is hand-rolled on Stripe, because Clerk Billing does neither one-time payments nor multiple concurrent paid plans and this has to demonstrate both. Entitlement is derived from the price actually paid, read through a SQL view, and returned only by the api. Fulfillment uses atomic claims and action-triggered retries, without a separate queue or scheduler. Crashes can require admin recovery.
Stripe, Postgres, email and Fulfillment integrations live in apps/api. Web holds
a Clerk secret only for the web SDK's server-side identity handling. Optional
PostHog product analytics is a public web integration.
Where to start
If you want it running, start at Install and run, work through the provider pages you need, then deploy.
If you want to know what you bought before you change it, start at Architecture and read the section in order.
If you already know and want a name or a number, everything exact is under Reference.
What is not here
No tests, and none ship. Your tests are for your product, and a suite covering this repo's own behaviour is a suite you would delete. pnpm check and pnpm typecheck are the gate.
No admin UI for defining offers, no plan column, and no field anywhere that says what somebody bought. Those absences are load-bearing, and Entitlements explains what they buy.
No multi-currency, no organizations, no seats. Each of those is a deliberate edit rather than a missing feature, and the pages that touch them say where the edit starts.