Stacks
Technical configurations that evolve with your project.
Overview
Catalyst uses three stack configurations. Every project starts at Stack A for proof of concept, then graduates to B or C as requirements demand.
Key Principle
Start simple. Add complexity only when needed. The stack progression is one-way—you don't go back from C to A.
Stack A — Next.js Only
When to Use
- • Initial proof of concept
- • Validating UI/UX assumptions
- • Static marketing sites
- • Presentations and demos
Includes
- • Next.js 16+ with App Router
- • Tailwind CSS 4
- • shadcn/ui components
- • Mock data and static content
Decisions to Avoid
- • Choosing a database
- • Setting up authentication
- • Creating API endpoints
- • Integrating payment systems
- • Building admin panels
Stack A is intentionally limited. The constraints prevent you from making architecture decisions before understanding requirements.
Stack B — Next.js + Supabase
When to Use
- • User authentication required
- • Data needs to persist between sessions
- • Real-time features needed
- • File storage required
Includes
- • Everything in Stack A
- • Supabase for auth and database
- • PostgreSQL via Supabase
- • Row-level security
- • Real-time subscriptions
- • File storage with Supabase Storage
Decisions to Avoid
- • Complex business logic in database
- • External API integrations (use C instead)
- • Custom authentication flows
- • Complex background jobs
Stack B is ideal for most SaaS applications. Supabase provides managed infrastructure that reduces operational burden.
Supabase Integration Scaffold
When upgrading to Stack B, follow these steps:
- Create Supabase project at supabase.com
- Add environment variables:
NEXT_PUBLIC_SUPABASE_URL,NEXT_PUBLIC_SUPABASE_ANON_KEY - Install packages:
npm install @supabase/supabase-js @supabase/ssr - Create
lib/supabase/folder with client utilities - Set up authentication middleware
- Migrate mock data to database tables
See A → B Checklist for the complete upgrade process.
Stack C — Next.js + Laravel
When to Use
- • Complex business logic
- • Multiple third-party integrations
- • Background job processing
- • Custom authentication requirements
- • Existing Laravel expertise on team
Includes
- • Everything in Stack A
- • Laravel API backend
- • Full PHP ecosystem
- • Queue and job processing
- • Custom API design
- • Advanced caching
Decisions to Avoid
- • Over-engineering for simple CRUD
- • Building when Supabase would suffice
- • Creating custom auth when not needed
Stack C is for projects that genuinely need a full backend. Don't choose it just because it's familiar—Stack B handles most cases.
Laravel Integration Scaffold
When upgrading to Stack C, follow these steps:
- Set up Laravel API project (separate repo or monorepo)
- Define API contract (OpenAPI/Swagger recommended)
- Add environment variable:
NEXT_PUBLIC_API_URL - Create
lib/api/folder with API client utilities - Implement authentication flow (typically Laravel Sanctum)
- Set up CORS and API versioning
See A → C Checklist for the complete upgrade process.
Typical Progressions
A → B
Most common. Add persistence and auth when POC is validated.
- • Add Supabase project
- • Migrate mock data to database
- • Implement authentication
- • Add row-level security
A → C
When complex backend is known upfront.
- • Set up Laravel API
- • Define API contracts
- • Implement authentication
- • Connect Next.js frontend
Note: B → C is possible but rare
If you start with Supabase and later need Laravel, plan for data migration and API redesign. This is significant work.
Stack Selection Checklist
Use this to decide which stack fits your project:
Next Steps
See Upgrade Checklists for the specific requirements when transitioning between stacks.