Rebuilding a live multi-tenant platform without downtime.
CORE Home was live with pilot brokerages when Danubio took ownership of the stack. The rebuild migrated tenants one at a time onto a stronger foundation, with no cutover and no broken clients. The same platform now carries 5,000+ tenants across web and mobile.
Live product. Real tenants. No window for downtime.
CORE Home was already running. Web and mobile both existed. A small number of pilot brokerages were live with real homeowners and real data.
The inherited system had done its job getting CORE Home to market. The next phase needed a foundation that could carry it: more brokerages, full white-label rollout, a product the business could own long-term. Danubio stepped in, took full ownership of the stack, and rebuilt it underneath the running product.
Each brokerage shows up on the platform as a tenant: a configuration that can range from default-branded to fully white-labeled with its own domain, app names, and theming.
Three shifts in the inherited product.
The backend was too brittle for the next phase of the product.
The inherited backend was tangled enough that a change in one surface could reach further than expected. Performance under real-world load was already a problem, and the system wasn’t sized for where the product was going. The roadmap pointed at millions of homeowners, not thousands.
The rebuild moved core behavior onto Laravel, matching the client’s broader stack and hiring profile, with clear separation of concerns. Search, valuation, notifications, and the rest now sit in services that can scale independently.
A foundation that has carried the product from pilot brokerages to 5,000+ tenants and 2M+ homeowners without re-platforming.
Launching a new brokerage was still a manual, high-touch process.
Provisioning a new brokerage still depended on coordinated setup work across branding, domains, account records, and mobile release steps. That was manageable for a small number of clients, but it did not scale cleanly with every new deployment.
Tenant provisioning became infrastructure rather than coordination. A dedicated admin surface drives the operational workflow, and the same flow is wired into the client’s billing system so a branded tenant spins up automatically when a package is sold.
What used to take days of coordination is now triggered the moment a sale closes. New brokerages spin up in the background without engineering involvement.
Branded deployments could not keep growing as one-off builds.
Each white-label app used to carry its own build and release overhead. The more brokerages the product served, the more linear and manual the maintenance burden became.
The product was reworked around tenant configuration rather than forks. Branding, domains, app names, and feature toggles now live in configuration; web and mobile both run from the same shared codebase.
Branded and generic experiences from one platform. No per-tenant fork, no separate product to maintain.
Four decisions that kept tenants running while the platform changed underneath.
Pilot brokerages were already live across web and mobile. The migration path mattered as much as the architecture itself, so it was designed to keep risk small and reversible at every step, and to actually end.
Preserved API contracts
A coordinated migration release across web and mobile would have forced every live tenant to ship a client update the moment the backend changed. That was exactly the moment the rebuild had to avoid. So the rebuilt backend answered to the same endpoint contracts the existing apps already depended on, and slid in underneath without a client release tied to the swap.
Only one side moved during migration. That is what kept existing tenants safe.
Old and new systems, running in parallel
Two systems running side by side over one shared data layer, a parallel run with reconciliation. Both stacks served real traffic, the rebuilt backend was compared against the live one on the read paths and verified per tenant before any cutover, and it only had to be correct for one tenant at a time.
Both stacks live, with read parity verified between them throughout.
Per-tenant cutover behind feature flags
A platform-wide flip would have meant every tenant moved together, with no way to pause for a single broken case without rolling everyone back. So tenant cutovers were gated through feature flags, a canary release run one tenant at a time. Each move could be staged, verified, and rolled back without touching the rest of the platform.
Each migration had its own verification path and a rollback contained to one tenant.
Retired the legacy platform once empty
Long-running parallel infrastructure tends to become permanent. Two systems quietly coexisting is its own kind of debt. This is the strangler fig pattern carried to its end: the migration only finished when nothing was left running on the old system, and with every tenant moved across, the legacy stack was decommissioned.
One platform to operate, no legacy stack to maintain.
One change reaches every surface at once.
A new tenant config takes effect across web and mobile at once. A branding update reaches every tenant as soon as the configuration changes. The product moves as one because the platform underneath it is one.
What looks like two products to the homeowner is two clients of the same system to the team. That’s what keeps web and mobile from drifting, and what makes shipping safe across every tenant.
Four years on, the foundation still carries the product.
- Both full white-label brokerage deployments and the generic unbranded experience
- Tenant provisioning automated through a single endpoint the client calls when a package is sold
- Same foundation has carried the product for four years without a re-platform
What the market said about CORE Home.
This innovative solution solidifies the long-term relationship between our agents and their customers, by putting them at the center of every stage of the homeownership lifecycle.
CORE Home has given our agents the tools they need to easily stay relevant to their clients before, during, and long after the transaction has closed.
Brokerages running on the platform today.
Over the years Danubio has become the partner we turn to when the work is critical and there's no margin for error. CORE Home was exactly that. They rebuilt the platform underneath the running product without taking a single tenant offline. The kind of team you wish you'd had from the start.
Frequently asked questions
How do you rebuild a live platform without downtime?
Rebuilding a live multi-tenant platform without downtime depends on migrating customers one tenant at a time while the old and new systems run in parallel. On CORE Home, Danubio took ownership of the running stack and rebuilt it underneath the live product with a strangler-fig approach: the new system grew alongside the old one, and brokerages moved across individually. Each tenant had a single writer during its move, so the two systems never disagreed about the same data, and every migration was verified read-first before write traffic shifted. Any tenant that showed a discrepancy stayed on the old path until it was resolved. The result was no maintenance window, no big-bang cutover, and no broken clients across 5,000+ brokerages, on a foundation that still runs four years later without a re-platform.
What scale does the platform run at today?
The platform CORE Home runs on today carries more than 5,000 tenants, 100,000+ real-estate agents, and 2M+ homeowners across web and mobile, serving over 2 million requests a day. That same foundation has held for four years without a re-platform, which is the more telling number: the architecture Danubio built during the live rebuild absorbed years of growth in tenants, users, and traffic without needing to be torn down again. The stack behind it is Laravel and PHP on the backend, React and React Native on the client, PostgreSQL for data, and AWS for infrastructure. Scale here is multi-dimensional, the count of isolated tenants matters as much as raw request volume, because each brokerage runs as its own configured, often white-labeled instance of the product.
What is a tenant on CORE Home?
A tenant on CORE Home is a single brokerage running its own configured instance of the product. Configurations range from default-branded, where the brokerage uses the standard CORE Home look, to fully white-labeled, with a custom domain, app names, and theming, so end customers experience it as software from that brokerage. New tenants are provisioned through a single endpoint that Inside Real Estate calls when a package is sold, which makes onboarding a brokerage an automated step rather than a manual setup. This tenant model is why the platform reaching 5,000+ tenants is significant: each one is an isolated, individually configured environment, and the architecture has to keep them separate, consistent, and correct while serving more than 2 million requests a day across all of them.
Rebuilding a product that already has users?
Danubio takes over live products, replaces tangled foundations, and migrates real users into something that scales. If you have users on a foundation that wasn’t built for what’s coming, let’s talk.