One system beats five integrations
Every tool an organisation adds is another export, another sync that silently stops, another place a member's email address is now wrong. Modules that share a database do not need reconciling.
About
Built for the people who keep a community together
Metrolo started from a familiar mess: a membership spreadsheet nobody trusted, an events tool that did not know who had paid their dues, a mailing list going to addresses from 2016, and one alumni officer holding all of it together by memory.
The organisations we kept meeting had the same shape. A roll of members that had drifted out of date because updating it was somebody’s unpaid evening. Events run through a general-purpose ticketing site that had no idea who was a member. Dues chased by hand. A donation history in a different system from the donor’s contact details. And underneath all of it, a legal obligation to know exactly what you hold about several thousand people and to delete it on request.
The tools that existed either solved one slice of that well and ignored the rest, or bundled everything into a platform where half the modules were locked behind a tier nobody could justify. Neither approach fixes the actual problem, which is that a member is one person and their record should be one record.
So Metrolo is one system. Fifteen modules over a single database, presented as a public website, a member portal and an admin panel. Each deployment belongs to one organisation, on their own domain, carrying their own name. No shared tables, no revenue share on what you collect, no module held back to create an upgrade path.
Every module was written against a functional specification before a line of it existed, and every endpoint has tests covering what happens when the request is right, when it is unauthorised, and when it is malformed. That is a slower way to build. It is also why we are comfortable telling you exactly what is finished.
What we believe
Six positions we are not planning to change
They shape what gets built, what gets refused, and how a demo call goes.
Data protection is not a feature tier
Export, erasure, versioned consent and an audit log ship to every customer on every plan. They are obligations, and selling them as an upgrade would be a strange thing to do.
Say what is built and what is not
Our roadmap has things on it that are not finished, and we will tell you which. A demo that quietly shows a mock-up is a problem you discover in month three, not on the call.
Volunteers are the real users
Much of this software is operated by a committee member on a Tuesday evening. If a screen needs a training session, that screen is wrong.
Boring infrastructure, deliberately
Nginx, PHP-FPM, a Node process, a queue and a scheduler. Nothing exotic, because a deployment your own IT team can understand is one they can keep running.
The answer comes from a person
Support is a named human who knows your deployment, not a queue position. There are fewer customers than a self-serve product would have, and that is on purpose.
Come and pull Metrolo apart
Bring your hardest question — the renewal edge case, the chapter that does its own thing, the data protection officer's list. Those are the calls we like.