The Problem: Fragmented Agency Operations
An event agency can have a calendar, a client directory and an invoicing process and still struggle to coordinate its work. Before WhiteMarker, project finances lived in spreadsheets, team availability in separate calendars, invoices in documents and vendor communication in email threads. A changed date had to be carried across those tools; a changed package affected both delivery and the amount owed. Coordinators became responsible for keeping several descriptions of the same event consistent.
Three recurring problems shaped the application: limited visibility into capacity before accepting work, manual follow-through on installment payments, and repeated communication between clients, contractors and vendors. I engineered WhiteMarker end to end to bring scheduling, people, commercial commitments and financial progression around one project context. The objective was a usable operations system in which staff could move from an availability decision to delivery without rebuilding the event's context at each step.
The Operational Model: Capacity Before Commitment
The custom yearly/monthly capacity matrix gives an agency a view of its workload beyond the next appointment. Twelve months, a selected day, upcoming events and colored operational states share the same planning surface. Inquiry, Booked, Blocked, Canceled, Meeting, Editing and Done are visible in the historical product UI, showing that the workload includes sales activity, unavailable dates and work after the event itself. Owners can examine the year's shape while retaining enough near-term context to open and coordinate a specific event.
The current calendar architecture preserves the meaning behind that view. Projects, pending inquiries and blocked dates remain distinct resources, composed into calendar projections for the requested months. An inquiry represents possible work, a project carries the operational record, and a blocked date records unavailable capacity. Keeping those distinctions allows the calendar to present them together without turning an unconfirmed lead into a booking or manufacturing a project simply to block time.
The Project Workspace: Keeping Changes in Context
An event workspace keeps its date, location, time and status beside financial summary, funnel stage, package, lead source and planner/producer context. Client, Team, Services, Vendors, Bookkeeping and Notes tabs expose the working detail while the event remains identifiable. This matters because moving a date can change participants' availability, delivery deadlines and the operational timetable; changing a package can affect service scope and finance. The workspace gives coordinators a place to understand those relationships before committing related edits.
The current implementation coordinates complex edits through workspace sessions, staged changes and revision-aware save/discard behavior. The backend checks the project and draft revisions, validates permissions and uses mutation identities to recognize retries. The frontend reconciles committed resources into TanStack Query and refreshes affected project and calendar projections. That boundary helps related edits stay coherent without treating every field change as an unrelated final mutation.
People, Services and Operational Handoff
Client and partner context, vendor relationships and team assignments make the event actionable. A tenant-managed contact can carry client, team-member or vendor profiles, while project assignments describe that participant's role in a particular engagement. A planner is represented through vendor capability and assignment rather than a disconnected identity. Removing an assignment archives the relationship to the project while preserving the shared contact.
Services connect the booked package to included deliverables, optional extras and an event-relative delivery deadline. The run-of-show then expresses the work as timed milestones for the people delivering it. Together these surfaces carry a commercial promise into operational handoff: who is involved, what has been sold, when it is due and what must happen on the day. The deeper relationship and timeline views are explored in the full WhiteMarker engineering case study.
Finance and Integration Boundaries
Bookkeeping places package context, discount, tax, processing fee, installments, deadlines, payment states and invoice controls within the event. Its In/Out tracking gives coordinators visibility into ad-hoc income and delivery costs alongside the payment schedule. This reduces the need to consult a separate spreadsheet to understand how an event's commercial commitment is progressing.
The current finance model uses versioned commercial snapshots and payment plans, with distinct invoice, payment, allocation, reversal and payout resources. Settlement derives from financial records rather than a mutable paid/unpaid flag, preserving the history needed to explain a remaining balance or refund. Stripe Connect links tenants' own Standard accounts; signature-verified provider events, persisted operations and idempotent retries connect payment infrastructure to the internal ledger.
Historical WhiteMarker delivery included two-way Google Calendar synchronization to align project scheduling with connected calendars. The current architecture places Google Calendar OAuth, writable-calendar selection, integration state and encrypted credentials behind a server-owned boundary. This keeps provider access within tenant permissions and separates calendar connection management from local project and capacity state.
Current Architecture and Access
WhiteMarker uses Bun workspaces to organize its React 18/Vite 6 frontend, NestJS/TypeScript backend and shared contracts. React Router 6 owns navigation, React Hook Form owns form drafts and local React state owns interactions. New and migrated server resources use TanStack Query, with legacy Redux retained only for remaining compatibility surfaces; Storybook supports component development. Zod 4 schemas, generated OpenAPI 3.1 types and a shared API client define the contract boundary, while Prisma 7 persists tenant-owned operational and financial resources in PostgreSQL.
Better Auth owns sessions and active tenant selection, with tenant-scoped RBAC enforcing permission-gated operations. The historical product served Super Admin, Admin, Client, Contractor and Vendor roles; the current authorization model expresses access through tenant memberships, roles and permissions. WhiteMarker's PostgreSQL outbox records Stripe provider work, with BullMQ/Redis workers supplying wake-up and retry processing where that asynchronous path is enabled. These boundaries let the application coordinate shared work while keeping identity, resource ownership and external services explicit.
Historical Outcomes and End-to-End Ownership
During the historical project period, WhiteMarker's custom capacity system achieved zero double-bookings, and the platform managed 1,400+ events in its first year. Calendar synchronization supported schedule alignment, while installment and invoice automation reduced payment-chasing and administrative work. Projects, people, scheduling and finance were consolidated into one operational workflow. These are historical project outcomes, not measurements collected for this portfolio update.
My ownership covered application architecture, frontend, backend, access logic, custom capacity planning and integrations. The full WhiteMarker engineering case study explains how those responsibilities connect across inquiry, project delivery and financial history. If your agency's bookings, assignments and payments need a shared operational context, let's discuss your workflow.