Architecture decision
Two related but different questions: how RealEZ isolates one brokerage's data from another (multi-tenancy), and whether a brokerage can run RealEZ under its own brand (white-label). One is required from day one. The other isn't, but it's cheap to keep open.
Do we pick this up in the first 6 months?
| Multi-tenancy (data isolation) | Yes — required, month 1 |
|---|---|
| White-label (branding activated for a partner) | No — deferred, but architected for now |
Every brokerage in the pilot — even if Phase 1 only ever signs one — is a tenant, and Full Pilot's plan explicitly targets 1–2 pilot brokerages across 2–3 states, so this is real from the first real customer, not a hypothetical future need. Retrofitting tenant isolation into a schema built without it is one of the most expensive mistakes to fix later in a multi-customer SaaS product — every table, every query, every access-control check has to be revisited. Building it in from the first migration costs almost nothing extra; adding it after the fact means an audit of the entire codebase.
brokerage_id column enforced at the query layer, not just an application-level convention — rather than a separate database per brokerage. Simpler to operate at pilot scale, and the standard pattern for a B2B2C SaaS at this stage; a database-per-tenant model is worth revisiting only once brokerage count and per-tenant data volume genuinely justify the operational overhead.Worth asking early specifically because of how the competitive landscape works: Updater and MoveEasy — the closest precedents to RealEZ's own marketplace model — are both white-labeled to brokerages as a client-retention perk, and RealEZ's own revenue model (referral commission on post-closing bookings) is loosely modeled on that same two-sided structure. A brokerage running RealEZ under its own name and domain, with RealEZ invisible as the underlying platform, is a plausible and valuable future product shape — the same way Updater is invisible behind the brokerages that use it.
It's not Phase 1 scope. The pilot runs under RealEZ's own brand, with 1–2 named pilot brokerages. Building a full white-label activation flow — custom subdomains, branded email sending domains, a self-serve branding config UI — before the core product (the two pillars, the transaction flow) is proven with real users would be solving a problem that doesn't exist yet, at the direct expense of time spent on what does.
The multi-tenancy work above already does most of the hard part — once data is properly tenant-scoped, white-label is mostly a presentation-layer problem, not a data-model problem. The cheap insurance to take now:
If a brokerage partner wants white-label post-pilot: turn the tenant-branding fields into a real settings UI, add custom domain/subdomain support, wire branded email sending (a verified sending domain per tenant), and decide the commercial terms (does white-label change the revenue split, given RealEZ's brand visibility — and therefore its own brand-building — goes away for that tenant). None of this is a rebuild if the month-1 groundwork above is done; all of it is a rebuild if it isn't.