RTM SaaS — A Building Operating System for Self-Managed Residential Buildings#

A modern, resident-focused operating system for buildings that manage themselves — RTM companies, RMCs, and their successors — built around clarity, transparency, and ease of use for non-professional operators.

Origin#

This started from a concrete situation: a UK residential development transitioning to Right to Manage (RTM) control, triggered by a ~300% service-charge increase over three years. The initial question was “which software should the RTM company use?” but it quickly reframed into something more interesting: the existing tooling is built for professional managing agents running portfolios of buildings, and appears to under-serve the small entity taking over its own single building. That gap is what this idea set out to examine.

The goal was never a committed build — it was to work out what such a system would need to do and whether it was worth playing with a prototype. This document records that exploration and the conclusion it reached.

What the idea survived, and what it didn’t#

The idea was stress-tested from a blank slate — deliberately not assuming the early conclusions were correct. Several held up, one reframed the whole thing, and one killed it as a solo project. They’re recorded here so the reasoning doesn’t have to be rediscovered.

1. Is the market real, or a gap “for a reason”?#

The self-managing segment is almost certainly much smaller than the raw RTM count suggests. Exercising the RTM right is about wresting control from the freeholder’s agent — it does not oblige anyone to self-manage. A very common path is: form the RTM → take over → appoint a different, chosen managing agent. Tellingly, even the building that sparked this idea — with the strongest possible motivation to DIY (a 300% cost shock) — will probably still outsource. If the most-motivated case defaults to an agent, that’s real evidence about the base rate.

Two readings of the gap:

Structural — the small-self-managing-RTM segment is a bad business: its customers exist to cut cost (so they’re the most price-sensitive buyers imaginable), their volunteer directors churn (terrible retention), they’re fragmented and unreachable (high CAC on tiny ACV), and non-experts need more support per pound of revenue. A gap where competent, funded incumbents choose not to play is often a gap for a reason.
Nascent — alternatively the market barely existed until recently, inflated by rising costs and recent leasehold legislation. If so, incumbent absence isn’t evidence it’s bad, just evidence they haven’t turned to look. This is the more hopeful reading, but it can’t be validated by studying incumbents — only by talking to buildings currently forming RTMs.

Both are probably partly true. The honest version of the pitch is “a tool for the minority who genuinely DIY” — not “9,700 RTMs.”

2. The durable unit is “a self-managed building”, not “the RTM company”#

The same legislative wave inflating RTM formation is also pushing toward commonhold and the reform of leasehold. Building the product tightly around the RTM legal vehicle (its statutory notices, the takeover claim, the leaseholder/freeholder split) risks wrapping software around a legal artefact that’s being reformed underneath you.

The fix: make the product primitive “a building that manages itself” — RTM today, RMC, share-of-freehold, or commonhold association tomorrow. RTM becomes the beachhead and marketing hook (that’s where the acute pain and the forming-now energy is), not the core entity. Commonhold associations self-manage by definition, so a commonhold future becomes a tailwind rather than a threat. (This also means the working name “RTM SaaS” is already too narrow.)

3. ICP boundary: shared governance + shared budget#

The idea briefly tempted itself with “even a household could use it” — a red flag, not a feature. The reason a self-managed block needs a system is a specific cluster a household entirely lacks:

Multiple stakeholders who don’t trust each other by default and need shared visibility;
Shared money — a common pot (service charge) that must be accounted for and justified to those stakeholders;
Shared liability & compliance — fire safety, insurance, statutory consultation — where getting it wrong is a legal/safety failure, not a preference;
Rotating, non-expert governance — directors change, so institutional memory must live in the system, not in a person’s head.

ICP line: a property with shared governance and a shared budget among non-professional stakeholders. Households and informal setups are out — chasing them drifts the product toward a generic home-admin app and dissolves its defensibility.

4. The painkiller vs. the £0 duct-tape stack#

Once accounting is (notionally) pushed to Xero and legal expertise stays with the advisor, what’s left inside the product is issue tracking, comms, document storage, and a governance log — a coordination layer over tools people already have for free. The real competitor is not Blocks Online or MRI; it’s the £0 duct-tape stack: a WhatsApp group, a shared Drive folder, a spreadsheet, email, and an accountant they were paying anyway. That stack is free, familiar, zero-onboarding, and already exists the day the RTM forms.

For the most cost-averse buyer in the market, “a nicer version of things I can do for free” is a vitamin, easily deferred. To win, the product needs a painkiller the duct-tape stack structurally cannot provide. The strongest candidate: institutional memory + auditable transparency across rotating volunteer governance — the record of why we chose this contractor, when insurance renews, where the last fire-risk assessment is, here’s the timeline proving the directors didn’t mismanage the money — which the free stack loses the moment the one organised director steps down. Issue tracking and comms are table stakes, not the reason anyone switches.

5. The crux — financial transparency is service-charge accounting#

The vision settled on the product as a hub: a long-term memory of owner-raised issues tied to estimates and invoices; an owner portal showing each owner’s statement of account and amount owed, documents, and policies; a ticketing system (issues raised by owners or by scheduled maintenance, tracked to resolution); multi-unit ownership under one login; management-side reporting on building state and cost trends; and reading proposed-work estimates to present each owner their apportioned share for communal voting.

Every financial element there is an output of a service-charge ledger — and that ledger is precisely the hard, regulated part the idea hoped to avoid. The uncomfortable realisation: you cannot have the transparency painkiller and fully decouple the accounting, because the transparency is the accounting, surfaced nicely.

The precise, verified finding:

General accounting packages (Xero, QuickBooks) do not do leasehold service-charge apportionment or per-leaseholder demands. Service-charge funds are client money, tracked as liabilities separate from business income.
The real market pattern is a two-layer split: a property-management layer owns apportionment, demands, work orders, and positions, and syncs to Xero, which holds the books. This is exactly how Arthur Online (UK residential leasehold) and Re-Leased (commercial) operate — “market-leading Xero integration”, two-way embedded sync, “generate accurate apportionments then sync bills and journals to Xero”.

So the correct statement is not “this must become a full accounting system” (too strong) and not “just read balances from Xero” (impossible — Xero has no apportionment to read). It sits in between: the product must own a service-charge sub-ledger — the apportionment schedule, demands, arrears, and a positions mirror synced to Xero — while the actual books and statutory year-end accounts stay in the accounting package.

Conclusion — shelved#

The idea is sound as a product observation: there is a plausible, possibly-nascent gap for a resident-focused “operating system for self-managed buildings”, and the strongest value is institutional memory and auditable transparency for rotating volunteer directors. It reframes cleanly around the durable unit (a self-managed building, not the RTM vehicle) with a defensible ICP (shared governance + shared budget).

It is being shelved for a scope-versus-resources reason, not a bad-idea reason:

The only coherent version of the product owns a service-charge sub-ledger synced to an accounting package. That sub-ledger is correctness-critical and semi-regulated — an apportionment or demand error has legal consequences, and disclaimers don’t cover arithmetic. Bidirectional Xero sync adds real reconciliation and drift burden (“why doesn’t the portal match the accounts”).
Building that responsibly is a funded effort involving accountants and lawyers — not something to attempt as a solo proof-of-concept.
It would still be sold into the price-sensitive, churny, fragmented volunteer segment established above.

The non-financial half (memory, ticketing, comms, compliance register) could be prototyped alone — but stripped of financial transparency it collapses back toward a vitamin competing with the free duct-tape stack, so it wouldn’t meaningfully test the thesis.

Net: a genuinely interesting reframing exercise that clarified where the real value and the real cost both live — and confirmed that the cost gates it out of solo-PoC territory. Worth revisiting only alongside funding and professional (accounting/legal) partners.