Glossary
Key Catalyst terms explained in everyday language. Use these consistently in conversations, docs, and code.
Delivery Workflow
How Catalyst projects move from idea to production
Delivery Loop — What you do repeatedly
Every feature, every sprint, every major update follows this rhythm. You'll cycle through these delivery phases many times at each stage. Each phase has a natural checkpoint — a moment to confirm you're ready to move on.
Brief
Define what you're building and why
Capture intent. First cycle = establish direction. Later cycles = update with learnings.
Build
Ship working software
Work with Coding AI. Follow conventions. Make it real and ready to show.
Review
Get feedback on the real thing
Show stakeholders. Validate intent against reality. Capture what you learn.
Refine
Decide what changes
Update the brief with learnings. Prepare for the next cycle, or decide to advance.
Advance
After several cycles, when the work is validated and solid, advance to the next stage. This is a deliberate decision — not automatic.
Stages — Where you are
Each stage has different expectations for what "good" looks like. Don't overbuild early, don't underbuild late.
Validate the idea works. Rough is fine.
Working demo, happy path only
Real users, real data. Core flows work.
Auth, database, error handling
Ready for paying customers. Polished.
Polish, security, performance
Enterprise-ready. Fully hardened.
Monitoring, backups, SLAs
Stacks — How you configure the kit
Choose the stack that fits your project. You can start simple and add complexity later.
Simple
No database, no auth
Best for: Landing pages, marketing sites
Supabase
Auth + Postgres included
Best for: Apps with users and data
Laravel
Custom API backend
Best for: Complex enterprise needs
Development Kit
How the Catalyst codebase is structured
Foundations — Basic terms you'll encounter
If you're new to web development, these terms come up constantly.
A URL path that displays a page
Example: /docs/core/glossary shows this glossary
The content shown at a specific URL
Example: Each route has a page.tsx file
Shared structure that wraps multiple pages
Example: Header, sidebar, footer — stays consistent
Where code runs
Example: Dev (local), Preview (test), Prod (live)
Central settings file (lib/config.ts)
Example: App name, feature flags, external links
Surfaces — Different experiences in one codebase
Your platform might have marketing pages, a dashboard, documentation, and presentations. Each is a surface with its own layout.
(web)For Visitors
Header + content — Marketing, landing pages
(app)For Users
Sidebar + header — Authenticated dashboard
(docs)For Developers
Sidebar + accordion — Documentation
(present)For Stakeholders
Full-screen slides — Presentations
Components — Building blocks
Core Components
Layout and typography primitives
e.g. Stack, Row, Grid, Text, Title
components/core/UI Components
Interactive elements (shadcn)
e.g. Button, Dialog, Input, Tabs
components/ui/Shared Components
Project-specific composed components
e.g. StatCard, LabelValue
components/shared/Layout Components
Shell building blocks
e.g. Shell, Sidebar, Header
components/layout/Other terms you'll see
The layout wrapper for a surface. Composes sidebar, header, and content areas.
A design system value (colour, spacing) defined as a CSS variable. Ensures consistency.
A predefined style option for a component. Like Button variant='ghost' or Text variant='muted'.
A document that captures decisions: Vision, Architecture, Voice, PRD, State of Play.
Quick reference
Ready to start building?
Jump into the quickstart or explore the approach.