What was happening
Three brands across the US, eastern Canada and western Canada, plus a London operation, all growing at once and all wanting their own tooling. The group was moving roughly CA$5M of rent a month through a mix of a legacy system, spreadsheets and about twenty separate payment accounts. Every brand that built its own stack would have tripled the maintenance bill and split the operating data.
What we did.
- 01
Ran the technology programme across all three brands as one roadmap rather than three, with a single core product deployed three times.
- 02
Specified the modules that mattered operationally first: bookings, inventory, move-in and inspection, move-out notice, and reconciliation across the payment accounts.
- 03
Wrote requirements as build-ready user stories so the delivery team could execute without a translation layer, and locked the spec before design rather than after.
- 04
Put a release-notes discipline in place so leadership could see what shipped each cycle, which is what kept the programme funded.
- 05
Separated lease end date from notice-based move-out date, a one-line data model change that had been causing inventory to be wrong for months.
on a single backend, deployed three times
~4,000 rooms
Where it landed
- One backend serving three brands and four geographies, with regional behaviour as configuration.
- Inventory accuracy fixed at the data model rather than patched in reporting.
- A visible shipping cadence that survived a change of leadership attention.
What we are not claiming
This was a programme role over more than a year, not a 30-day build. It is here because it is the clearest example of what we mean by choosing the boring architecture on purpose.