Public Visitor
Discover the organization
Editorial content (programs, events, articles, gallery) is fetched directly from Sanity CMS and remains accessible without an account.
Programs, events, blog, gallery, contact
Independent Software Product
CREATIVE WORK, CONNECTED.
Studio Pulse connects public discovery, member participation, and organizer operations while keeping editorial content and authenticated application data under explicit ownership boundaries.
- Role
- Full-Stack Developer and Product Designer
- Timeline
- June 2026 - Present
- Status
- In Development
Overview
One product for sustained engineering decisions.
I started Studio Pulse as a long-term product where architecture, authentication, data ownership, testing, and deployment decisions could be evaluated together instead of across disconnected demonstrations.
The codebase evolves through working public, member, and organizer workflows. Each revision is reviewed against clearer ownership boundaries, recoverable failure states, and maintainable interfaces.
Product surfaces
Three connected experiences, one application.
The public website, member portal, and organizer workspace serve different responsibilities while sharing the same product direction.
Member
Participate without losing context
Authenticated users manage profiles, save events, register for limited-capacity events, and review personal participation history.
Dashboard, saved events, registrations, profile
Organizer
Operate behind the scenes
Role-protected back-office tools manage registrations, contact messages, newsletter subscribers, and tasks, while providing a read-only view of published CMS content and linking authorized editors to Sanity Studio.
Overview, inbox, registrations, tasks, published content, Sanity Studio
Registration workflow
Coordinating limited-capacity registrations across separate providers.
Event content and capacity are managed in Sanity, while member registrations are stored in Supabase. When a member requests a place, the application verifies the current event and delegates the registration operation to PostgreSQL.
Within the normal member workflow, the database function serializes same-event registration calls, checks existing and capacity-consuming registrations, and then inserts or reactivates the authenticated member’s registration within one database transaction.
- 01Member
Request registration
An authenticated member submits a registration from the event page.
- 02Server Action
Authenticate and validate
The Server Action verifies the member’s session, validates the event slug, and invokes the registration use case.
- 03Application Use Case
Verify the event
The use case retrieves the current Sanity event and confirms that it remains available for registration.
- 04Supabase Repository
Delegate the database operation
The repository calls Supabase’s public.register_for_event PostgreSQL function with the event identity and published capacity.
- 05PostgreSQL RPC
Serialize and persist
The function uses transaction-scoped advisory locking to serialize same-event RPC calls, checks for an existing registration, counts pending and confirmed registrations, and inserts or reactivates the member’s registration.
Architecture
Different responsibilities, explicit provider boundaries.
Studio Pulse uses a feature-based modular monolith with pragmatic Clean Architecture principles. Sanity manages editorial content, while Supabase manages authenticated application data. Feature use cases access those providers through interfaces and adapters, keeping provider-specific SDK clients outside the application use cases.
| Responsibility | System | Owned Data |
|---|---|---|
| Editorial content | Sanity CMS | Events, programs, instructors, articles, and gallery content |
| Application workflows | Next.js | Routes, Server Actions, feature use cases, validation, and provider adapters |
| Authenticated data | Supabase / PostgreSQL | Identity, profiles, registrations, messages, subscribers, tasks, and RLS policies |
Security and verification
Authorization is enforced beyond route navigation.
Middleware and protected layouts guide navigation, while Server Actions, application use cases, repositories, and PostgreSQL policies enforce identity and permissions during data access and mutation.
Defense in depth
Protected mutations recheck identity and permissions at the server boundary.
- Route middleware
- Protected layout route guards
- Server Action identity & Zod validation
- Application use case rules
- Supabase repository data access layer
- PostgreSQL Row Level Security (RLS)
Verification Infrastructure
The repository includes Vitest domain and use-case tests, Playwright workflow coverage, TypeScript and ESLint validation, and Next.js production-build checks. Current execution status is tracked separately and is not implied by this list.
- Vitest domain and use-case tests
- Playwright end-to-end workflow tests
- TypeScript and ESLint validation
- Next.js production build verification
Retrospective
Key Architectural Observations
Connected workflows need clear ownership.
Bringing public discovery, member participation, and organizer operations into one application revealed where editorial content ends and operational state begins.
Provider boundaries create visible trade-offs.
Separating Sanity content from Supabase application data improves isolation and testability, but workflows involving both providers require explicit failure handling and synchronization decisions.