Rebuilding a 9-year-old condo management platform as multi-tenant SaaS

CondoGenie is a condominium management platform built to close the communication gaps between a condo board, its property manager, and the residents they serve.

The solution supports an infinite number of users and provides a rich set of powerful tools that let all the interested parties stay and communicate directly on one platform, and acquire urgent assistance with any problems that might happen to their housing.

CondoGenie at a glance

• Client

  Rafal Dyrda, CEO and Founder, condogenie.com, Canada

• Industry

  Proptech, condominium and HOA management

• Legacy system

  GeniePad, launched 2009

• Engagement

  2018 to present, ongoing

• First release

  18 months

• Services

  Application modernization, SaaS product development, senior engineering pod

• Architecture

  Three-tier multi-tenant SaaS with per-tenant subdomains

• Stack

  React, Ruby on Rails, Node, TypeScript, AWS Lambda, ActiveAdmin, PostgreSQL, Stripe, Rotessa, Twilio, Playwright, Sentry

• Property types

  Condominiums, stratas, HOAs, and co-ops

• Product type

  Condo management platform with a resident portal, property manager portal, maintenance tickets, and billing integrations

• Engagement model

  Senior engineering pod, 2018 to present

How GeniePad, a 2009 condo system, became CondoGenie

Rafal Dyrda is a Canadian entrepreneur who moved to a condominium in downtown Edmonton in 2003, joined the condo board, and built software to fix what he found there.

The tool he built for his own board became GeniePad, a product sold to condominiums across the United States and Canada, and Rafal joined the Canadian Condominium Institute on the back of it. This is the classic path of turning an internal tool into a SaaS, and it carries the classic problem with it. Nine years of features had accumulated on an architecture originally built for one building, and it could not carry the multi-tenant, self-serve product Rafal wanted to sell next.

He came to Brocoders in 2018 looking for a proptech software development team that could rebuild the platform without losing the customers already on it.

The first decision on CondoGenie: refactor GeniePad or rebuild it

Request

A brief that asks for new features, a new interface, and a new name can be delivered two ways, by extending the system that exists or by building a new one. That question came before any code.

Audit

We ran requirements elicitation with an in-house business analyst first, working through the existing system's behavior and its undocumented edge cases.

Verdict

The answer was to build new. So the development process was set up in accordance with the existing system, and the new platform was built from scratch. Every behavior the legacy system had was mapped and reproduced deliberately. That distinction is the whole engagement in one line: the rebuild was of the code, not of the product logic, which stayed continuous for users who had been on GeniePad for years.

Rebranding GeniePad as CondoGenie, and redesigning it without losing its users

Modernization is usually sold as backend work. On CondoGenie the visible half was the harder half, because the platform was being renamed at the same time it was being rebuilt.

Rafal asked for a complete rebrand, including a new product name. GeniePad, the name his customers had used since 2009, became CondoGenie. A rename of a live B2B product is a commercial decision before it is a design one, and it carried the whole interface with it.

Against that, one constraint from the client that shaped every screen. The majority of GeniePad's users were non-technical condo board members and residents who had learned one interface and had no appetite to learn another. The new product had to look current to a prospect and familiar to an existing user, at the same time.

So the design work ran as a loop rather than a handover. We built prototypes, Rafal put them in front of his real end users, and we changed them on that feedback rather than on design opinion. Development ran in Scrum with small increments, and each module was demoed to Rafal before it was accepted, with several demos for the Account module because of its size.

Multi-tenant architecture for condominiums, HOAs, and property management companies

CondoGenie is a multi-tenant SaaS platform. Three tenancy levels carry different permissions, different billing, and different administration:

Property managers, boards, owners, and renters each get their own view of the same account. Tenant workflows run through the resident portal: maintenance tickets, amenity bookings, document access, and building announcements.

Four user roles sit inside that structure and behave differently: administrators (board members and head-office staff) work in news, documents, buildings, and requests; managers work in forums, classifieds, and announcements; owners and renters live in the community and maintenance modules. Access control is enforced at category level across documents, forums, and forms, with default groups for owners, administrators, board members, and general residents.

Real multi-tenancy is proved by its edge cases. In August 2026 an account arrived with 34 buildings registered at a single street address, a shape the registration flow had never met. We found it, unblocked the account, and changed the flow. Unit numbering is configurable at account setup, odd, even, or sequential, for the same reason: condominium buildings in the wild do not agree on how to number anything.

We applied the same multi-tenant model later on an HOA management platform for a different client.

Migrating nine years of condominium data off GeniePad

Migrating GeniePad's existing user data into CondoGenie was the highest-risk part of the engagement, and it ran alongside feature development rather than after it.

Early migration runs surfaced schema mismatches and records that did not map cleanly, the normal result of moving data out of a system that had accumulated 9 years of exceptions. Every one was fixed or restored, under the release timelines the business needed to keep. Rafal's end users reported anything they spotted directly to us, which shortened the fix cycle.

The CondoGenie resident portal: 6 features at launch, 23 today

The first CondoGenie release took 18 months and shipped six features: news posting, document posting, tasks, calendar events, amenity bookings, and emergency SMS.

CondoGenie today runs 23: unlimited users and units, a public website and private resident portal, automated email notifications, news and announcements, AI news generation, unlimited document storage, FAQ, classifieds, message forums, requests, unit messages, SMS broadcasts, phone voice broadcasts, tasks, projects, reports, amenities and bookings, calendar, analytics, surveys, maintenance, parking, and forms.

Requests are the platform's maintenance ticket system, and 40% of resident requests are maintenance and repair, ahead of community rules and complaints at 15%, and document retrieval at 12%. The maintenance module was built on that distribution, with asset overviews, QR-code access to maintenance records, recurring inspection schedules, customizable checklists, and multi-user task assignment.

Building resident requests on top of the tasks module would have forced access-control compromises, because tasks carry permissions that residents should not hold. We reused and extended the requests module instead.

What CondoGenie does today: the full feature set

Twenty-three features, grouped the way a condo board and a property manager actually use them.

Paying down technical debt on a live condo management SaaS, 2018 to 2026

A condo management platform that was modernized once in 2018 and left alone would be legacy again by now. The larger part of this engagement is the technical debt work that keeps CondoGenie current while it serves paying customers, which is legacy application modernization performed continuously rather than as a one-off project.

Runtimes and build tooling are reviewed as they age out, scoped with the client, and sequenced into the roadmap alongside feature work.

Every one of those upgrades is proposed as a retention argument rather than an engineering one. A founder paying for development out of subscription revenue funds what keeps accounts, so we scope infrastructure work as the investment that keeps the platform ahead of the tools his customers could switch to. Condo management software competes with management companies building something in-house.

The current codebase runs 1,806 modules across 4,241 files in two repositories. Recent work against it:

• Ruby on Rails version upgrade

  Scoped June 2025, released 15 August 2025. Framework upgrade on a live platform with no customer-facing downtime.

• Test suite migration to Playwright

  June to September 2025. Full replacement of the existing suite, with the residual Cypress tests retired in 2026.

• Stripe API version migration

  February 2026. Payment API version upgrade against live subscriptions.

• Frontend toolchain modernization

  Scoped August 2026, in progress. Moving the build and runtime to Node 24.19.0 LTS ahead of the older versions reaching end of support, which requires replacing the retired CRA and Webpack builder, and that in turn unblocks the TypeScript and React upgrades.

• node-sass to dart-sass

  August 2026. Dependency retirement identified in the same scoping.

• Daily Summary query optimization

  August 2026. Removed a standing source of server CPU load.

• Global Settings restructure

  2025 to 2026. Tabbed navigation and centralized task categories, a structural refactor rather than a visual one.

Sentry runs in production, so defects surface to us before they reach Rafal or his customers.

That table is the answer to the question most SaaS owners arrive with. Their platform is on an unsupported framework version, they cannot pause the roadmap to fix it, and they need the upgrade sequenced so each step unblocks the next. Node before the builder, the builder before TypeScript, TypeScript before React.

Subscription billing and billing integrations for property management accounts

CondoGenie sells subscriptions to condominiums and management companies across four tiers, Inform, Communicate, Collaborate, and Manage, and until 2026 every plan change between them went through a human.

Plan Upgrade Automation was delivered on 13 May 2026. Accounts now change plan themselves, with the prorated difference calculated automatically for annual accounts, an invoice generated on the spot, and a 7-day payment window before the change lapses. Monthly-to-monthly and yearly-to-yearly shipped first, with the cross-period switches scoped as a second phase.

Billing also gained an active payment method display, immediate invoice generation on a plan switch, and date-range filtering. Payments run through Stripe for cards and Rotessa for Canadian pre-authorized debit, with Xero on the accounting side. On CondoGenie the annual accounts pay largely by pre-authorized debit, so a Canadian condo platform needs that rail alongside cards. A referral program reached staging on 31 August 2026.

Shipping an AI feature inside a modernized proptech platform

Condo boards write announcements, and most board members are volunteers who do not enjoy writing them.

Genie, released in August 2025, drafts announcements from a short prompt inside the news module. The client named it as a character rather than as a capability, and the button reads "Generate with Genie", which is the opposite of how condo management competitors present AI. It is live and in production.

The point for anyone weighing a modernization budget: the AI feature was possible because the platform had been kept current. A platform that has been left on end-of-life runtimes for a decade cannot absorb a feature like this quickly, whatever the budget.