We spent twenty years building the problem.

Bond Software Group has been building membership systems for Australian member organisations since 2006. Before I tell you about the platform we build now, I want to tell you what we actually built for most of those twenty years. Not the brochure version. The real one.

We built systems the way this entire industry built them. A core product, then customisation on top. Requirements workshops. Specification documents. Custom fields, custom workflows, custom reports, custom integrations. Every organisation slightly different, so every system slightly different. The work was serious and the people doing it were good. I would put our delivery record against anyone's.

Here is what that model produces, and I can describe it precisely because I watched it happen from the inside, over and over, for two decades.

Year one, the system looks like a triumph. It fits the organisation because it was shaped to fit. The board is happy. The launch email goes out.

Year five, the shape becomes the problem. The person who sat in the requirements workshops has moved on, usually on both sides of the relationship. The customisations that made the system fit are now the reason it cannot be upgraded. A change that should take a day takes a scoping call, a quote and a six week wait, because the only safe way to touch the system is through the people who remember why it works.

Year ten, the system still runs. It processes renewals. It sends the emails. And nobody in the building can fully explain it. It operates on the memory of one or two long serving staff and the goodwill of a vendor. It works. It does not hold.

I want to be careful about what I am claiming here, because it would be convenient to pretend this describes other people's systems. It does not matter whose logo is on the login screen. This is what the standard model produces, regardless of who sells it, and we sold it too. We were not the exception. We were good at the model, and the model was the problem.

The moment it became impossible to ignore was not dramatic. It was the same conversation, arriving again and again at renewal time. Organisations were not asking whether the system worked. They knew it worked. They were asking who still understood it, what it would cost to change anything, and what would happen when the person holding it together retired. Those are not product questions. They are questions about a model that concentrates knowledge in people instead of building it into the platform, and no amount of customisation fixes that, because customisation is the mechanism that causes it.

So we stopped.

I mean that literally. We did not refactor the old codebase and change the logo. We took everything twenty years had taught us about how member organisations actually run, how their data actually behaves, where these systems actually break, and we built a new platform that refuses the old model entirely. One data model the whole platform shares. Logic that lives in the product, not in the memory of whoever configured it. Behaviour a new staff member can read without a tour. A system designed so that explaining it costs nothing.

Every few years, someone new arrives promising to fix this industry. They usually have impressive technology and no scar tissue. They have never sat in the room while a board asks why the member numbers in the annual report do not match the database. They have never inherited a fifteen year old system and been asked to make it safe. The technology is the easy part. Knowing what it has to survive is the part that takes twenty years.

That is the honest shape of it. A new platform, built by the people who spent two decades learning, at their own expense and their clients' patience, exactly why the old one had to go. We are not asking anyone to trust a promise. We are asking them to trust a diagnosis, made by the people who lived inside the condition.

Here is the question I would put to any organisation reading this, whatever system you run and whoever built it. How much of your platform lives in the product, and how much lives in the memory of the people keeping it running? Because one of those survives a resignation, and the other one is a liability with a login.

We spent twenty years building the problem. That is exactly how we know what the answer has to hold.