The problem
This client already had a ticket-picker widget running inside their Swoogo group-registration page — that’s its own build, covered separately. What they also needed was a ticketing surface that didn’t live inside a Swoogo microsite at all, served instead directly off their own account on the backend admin platform.
The approach / solution
Built a dedicated ticketing front end as its own page on this client’s account within the multi-tenant admin platform — the same NestJS/TypeORM/PostgreSQL backend and SvelteKit frontend that runs each of the platform’s 33 client accounts. It stands apart from the Swoogo-side widget entirely: different codebase, different layer, no shared logic between the two.
Outcome / result
This client now runs ticketing on two separate surfaces: the Swoogo-side group-registration widget for registrants going through that flow, and this standalone front end for ticketing that sits outside Swoogo altogether. Two distinct builds, same client, genuinely different jobs.
Why it matters for enterprise event-tech
Not every feature a client needs fits inside a page-builder’s constraints. Recognizing when a capability belongs on the backend platform instead of inside the Swoogo theme layer, and building it there without dragging Swoogo-side logic along, is what keeps two systems from turning into one tangled one.
