Spend enough time around Singapore’s strata management scene and a pattern shows up everywhere, in estate after estate, regardless of who’s running it.
Take the Building Manager. On paper, the job looks simple: keep the estate running, get repairs done, report back. In practice, it isn’t. A good chunk of a BM’s time, often the majority, goes into relationship management rather than maintenance management — keeping the council happy, smoothing over egos, responding to whatever surfaced in the WhatsApp group that day. The work residents actually notice keeps getting pushed down the list.
Part of the reason is that there’s often no real process behind the job. No defined system for how a repair gets requested, approved, and closed out. So whoever is physically on-site ends up calling the shots by default — dealing with leaks, lift breakdowns, and tenant complaints at 7pm on a Friday, making decisions on the fly because someone has to.
Then there’s the council. Well-meaning owners volunteering their evenings, but their main point of engagement is usually questioning the repair bill after it’s already been paid. “Why did this cost so much?” “Did we need this vendor?” Fair questions — except most council members aren’t maintenance experts. They can’t easily tell if a quote is fair, if an invoice matches the scope of work, or if a vendor is even legitimate. So scrutiny lands on cost, after the fact, instead of on process, before the fact.
Nobody in this setup is doing anything wrong. The BM is doing their best under pressure. The council is doing what they believe their duty requires. But with no structure in place, every decision runs on memory, trust, and whoever picks up their phone first.
That’s not a people problem. It’s a systems problem. That was the first reason Basementgrid needed to exist.
The software that already exists wasn’t built for this
The natural next step was to look for software that solves it. CMMS tools exist, just not for this world. Almost all of them are built for an internal maintenance team — employed by the building, using the same system daily because they have no choice. Log a ticket, assign an in-house technician, close it out. That works fine when you’re giving orders to your own staff.
And to be clear, this isn’t a gap that apps like iCondo or iPlusLiving fill either. Those platforms are built for communal living — facility bookings, visitor management, resident announcements, the social side of condo life. Useful, but aimed at residents, not at the operational backbone of how repairs get requested, approved, and closed out.
But that isn’t how strata management works. An MCST doesn’t run on an internal crew — it runs on external vendors: plumbers, electricians, lift technicians, cleaners, landscapers, dozens of contractors moving between many buildings, not just one. The MA’s real job isn’t fixing things. It’s coordinating the vendors who do.
That’s where every existing CMMS falls apart. You can’t force a vendor to log into your system. They have no reason to. They’re not your employee — they’re doing jobs for twenty other buildings this week, each possibly running a different system, if any. Ask a vendor to create an account and update ticket statuses for a job worth a few hundred dollars, and the answer is a WhatsApp message instead. Every time.
So estates end up back where they started: coordinating over calls, texts, and memory — the same chaos as before, except now there’s also an expensive piece of software nobody uses sitting in the background.
That was the second reason Basementgrid was founded. Not “another CMMS,” but one built around the reality that MCSTs run on vendors, not employees — where getting vendors to actually participate is the core design problem, not an afterthought.
The part that only shows up over years
The third issue takes longer to see, because it doesn’t show up in a single site visit — it shows up over years. Managing Agents change, a lot. And the new one is often a company already familiar, recycled from another estate down the road.
It’s musical chairs. A new MA comes in, there’s a fresh start for a while, then a year or two later they’re let go too, and the whole cycle resets from zero: onboarding, learning the estate, rebuilding vendor relationships.
Most of the time, MAs aren’t let go over maintenance competence. It comes down to the Building Manager’s relationship with the council — and council members, however well-intentioned, usually aren’t professionals in this space. They’re volunteers with day jobs. So the relationship becomes the deciding factor, not the work. A BM who is well-liked survives. A BM who is competent but blunt, or slow to reply at 9pm, doesn’t. Maintenance work stalls not because it can’t get done, but because the relationship managing it keeps falling apart.
That’s not to say every BM is blameless either. Plenty aren’t well-equipped for the job. It’s something of an open secret that many BMs are retirees, hired to fill a headcount rather than for hands-on experience. So you get a BM who isn’t strong on process, managing a relationship with a council that isn’t strong on maintenance, with nothing structural holding the estate steady when the relationship sours.
That’s the third reason Basementgrid was founded. An estate’s operational history shouldn’t live and die with whichever MA happens to be in the chair this year. The work orders, vendor records, approval trail, maintenance history — that should belong to the building, not to whichever company or BM currently holds the relationship together. When the MA changes, and it will, the estate shouldn’t have to start from zero.
(More to come — this is where Basementgrid’s story really begins.)
Leave a Reply