We built a multi-tenant operations platform for an operator serving the niche but commercially significant world of livestock shows, county fairs, rodeos, and agricultural exhibitions.
The platform replaced an engineering-gated tenant onboarding process with a configuration-driven workflow.
A super admin spins up a new show organizer with sensible defaults. The show admin then configures the platform to fit their show: livestock categories, registration fields, approval flows, and pricing. No code changes, no engineering tickets.
Adding a new show organizer is a configuration exercise, not a development project. The operator can onboard new organizers during peak sales periods without waiting on engineering. Engineering is no longer on the critical path of commercial growth.
Every show organizer is operationally distinct. The user journey is more complex than ticketing. Engineering involvement bottlenecked tenant growth. Show-day traffic spikes broke generic SaaS assumptions.
A regional rodeo, a junior livestock show, a state agricultural exhibition, and a school-affiliated 4-H event need different livestock categories, registration fields, approval chains, and pricing. A single rigid template fits none of them.
Parents register on behalf of their children. The registration captures details of the livestock the child is showing. The child's ag teacher reviews and approves the entry. Only then does payment complete. This is a multi-party workflow problem, not an event-ticketing one.
The operator's commercial model depends on continuously adding tenants. When every new tenant required engineering setup, growth was capped at engineering capacity.
Registration windows compress a large share of the year's traffic into a short window. Steady-state architectures fail. The platform has to be designed for event-day load from the start.
Configuration-driven multi-tenancy. Super admin onboards a new tenant with default configurations. Show admins then configure their own livestock taxonomy, custom registration fields, approval flow definitions, and pricing rules through admin UIs. No engineering involvement, no code changes, no deploys.
A multi-party registration and approval workflow purpose-built for the domain. The parent or guardian registers on behalf of a child and captures the livestock being entered. The entry routes to the child's ag teacher for verification, then completes through payment. Each tenant defines its own version: who approves, under what conditions, in what sequence.
Resilient event-day operations stack. Per-tenant queue management, registration-window pre-warming, waitlists at capacity, and on-site check-in flows built for field conditions.
Super admin onboards a new tenant with default configurations. Show admins then configure their own livestock taxonomy, custom registration fields, approval flow definitions, and pricing rules through admin UIs. No engineering involvement, no code changes, no deploys.
The parent or guardian registers on behalf of a child and captures the livestock being entered. The entry routes to the child's ag teacher for verification, then completes through payment. Each tenant defines its own version: who approves, under what conditions, in what sequence.
Per-tenant queue management, registration-window pre-warming, waitlists at capacity, and on-site check-in flows built for field conditions.
Two architectural assumptions collapsed in the first weeks of real use. Treating this kind of platform as a normal SaaS product is a category error. Traffic arrives in event-day spikes, commercial stakes are high, and the architecture has to be designed for that from day one.
The metadata model treated tenant differences as configuration values inside a fixed schema. In practice, different show types needed structurally different fields and structurally different approval workflows, not just different values. We refactored to a tenant-level metadata schema with show-admin-defined custom fields and a workflow definition layer where approval chains are data, not code. That refactor made the configuration-driven model work; without it, every "configurable" claim would eventually have hit a hardcoded assumption.
The steady-state queueing model collapsed during registration-day spikes. We added per-tenant queue management, registration-window pre-warming, and waitlists at capacity. After that, registration day stopped being a recurring incident and became a normal operating event.
Can the operator onboard tenants without engineers? Yes. New tenant onboarding moved from several engineering days to a same-day configuration process. Super admin creates the tenant with defaults; show admin tailors the rest. Tenant acquisition no longer waits for engineering roadmap slots.
Can the platform survive registration day? Yes. Registration-day traffic was previously the source of recurring incidents. It now handles peak windows of 3,000 submissions per hour without engineering intervention.
Show organizers configure livestock categories, registration forms, approval flows, and pricing without raising tickets. Self-service configuration removed a large share of the onboarding and configuration support that previously hit engineering and support teams.
Can the operator scale revenue without scaling headcount? Yes. The operator now runs 10 active tenants on the same engineering team that previously serviced a fraction of that. Adding the next tenant no longer creates the same engineering setup work, so revenue scales with less incremental cost.
New tenant onboarding moved from several engineering days to a same-day configuration process.
Registration-day traffic now handles peak windows of approximately 3,000 registration submissions per hour without engineering intervention.
Show admins configure livestock categories, registration forms, approval flows, and pricing without raising tickets.
The operator runs 10 active tenants on the same engineering team that previously serviced a fraction of that.
Self-service configuration removed a large share of the onboarding and configuration support that previously hit engineering and support teams.
Adding the next tenant does not add engineering work.