Demo: a kanban board that ships

The second demo app is the one every team eventually builds by hand: a task board. One command generates it — schema, backend, and a nine-view page — from a declarative spec.

pnpm new my-app --demo tasks

The shape of the tracker

The spec defines one tasks entity with a title, two selects, an assignee, a due date, an estimate in hours, tags, and notes. The status select is your workflow — Backlog, Doing (accent), Review (warn), Done (ok) — and because it is the entity's statusKey, those options are the kanban columns. Dragging a card from Doing to Review is a status change persisted through the standard patch endpoint.

Priority is the second select — Low, Medium (warn), High (danger) — and its tones color the badges everywhere the field renders. dueDate feeds the calendar and timeline, so deadlines get a month view for free; estimate is the amountKey, so the stats view aggregates hours overall and per status — a small throughput dashboard nobody wrote. The demo defaults to the dashboard design with a violet accent and the header layout.

A seeded backlog

An empty board demos badly, so the spec carries a believable sprint: Sam is designing the onboarding flow (high, 8h, in Doing), Riley has billing webhooks in Review, the launch post sits in the backlog, a mobile-nav bug is already Done, a load test waits at low priority, and Alex's customer interview notes are in flight. The generated page offers Load sample data whenever the workspace is empty, and the seed refuses to duplicate itself.

The same spec, in SQL

Demos are specs, so they generate for either backend. On the Supabase variant the same spec becomes idiomatic SQL:

pnpm new my-app --demo tasks --db supabase

The codegen appends a tasks table to supabase/schema.sql with a CHECK constraint that mirrors each select's options exactly — status must be one of backlog, doing, review, done at the database level, not just in the UI. Row-level security is enabled with an own-rows policy, columns are snake_case end to end (due_date, not dueDate), and the page reads and writes through supabase-js directly, because RLS is the backend. Same board, same seed, SQL idiom throughout.

Expand it for your team

Your workflow probably has one more axis — sprints, epics, components. Adding it is a field modifier, and backend and frontend follow together:

pnpm new my-app --demo tasks --fields "+sprint:select:Sprint"

The new select lands in the schema (with its CHECK constraint on Supabase), in the shared option constants, in the generated form, and in the filter surface. Swap the placeholder options by editing one constants file, or hand a full spec file to --demo instead. Removing works the same way — drop estimate and the stats totals quietly disappear, because the views derive from the config.

The workflow is data, so changing the workflow is a flag.

Scaffold it, load the sample backlog, drag a card, and deploy. The task tracker your team was going to build next quarter took one command.