Skip to main content

​
Today

Tessera is a static site served by a single Cloudflare Worker.

​
How changes ship

Minor changes go straight to production and are live within about a minute. Big features are built on a branch, checked on that branch’s preview address, and then merged. The accessibility audit runs on every push. Cloudflare builds the component app on every push, so build output is never committed.

​
Toward a full-stack app

Tessera is meant to grow into a full-stack product with accounts, a database, and real AI calls, without a rewrite. The foundations that keep that path short:
The Worker that serves the site today can also run application code. An /api layer, a database (D1), file storage for uploaded course material (R2), and AI calls (Workers AI or AI Gateway) are added to the same deployment, next to the static site and the app.
Components get data through one small, typed interface, backed by sample data now and by API calls later. Components don’t change when the data becomes real.
The course → module → lesson → block structure, the tutor modes, and the AI draft states are TypeScript types that the future API reuses.
AI drafts with provenance, tutor modes, and “who sees what” are data from the start, so the server can enforce them later instead of leaving them as interface-only behavior.
When the API exists, its reference documentation will live here.