Multi-tenant from day one
“We'll add multi-tenancy later” is the most expensive sentence in platform engineering. Why Right Events was isolated from week one.
There is a sentence that shows up in almost every early platform spec, and it costs more than any other: "We'll add multi-tenancy later."
Later is a re-architecture
Tenancy is not a feature you bolt on. It is an assumption baked into every query, every cache key, every storage path, and every permission check. If you build for one tenant and add isolation later, you are not adding a feature — you are auditing the entire codebase for the absence of one, line by line, hoping you do not miss the query that leaks one organizer's attendee list into another's dashboard.
When we built Right Events, every event organizer got isolated data, custom branding, and a unique sub-domain from the first week. The data model assumed many tenants before there was a second one.
What that bought
It bought self-serve onboarding. Today a new organizer can spin up a branded event site with custom domains, logos, and content, and Elyshub never touches it. Seventy-plus events have run through the platform with zero cross-tenant incidents.
Build the second tenant before you have the first. The architecture you get is the one you would have wished for anyway.
The discipline is uncomfortable early — you are solving a problem you do not visibly have. But the alternative is solving it under load, in production, with real customer data on the line.