A customer asked us recently why they couldn't just build Q-Bridge themselves.
Q-Bridge is our automated data sync product. It connects to Rubixx HMS via their Open API Warehousing Collection, reads the JSON from paginated endpoints, restructures it into a clean relational database, and puts customers' own data in their hands — so they can build out their reporting in Power BI, Tableau, SSRS, or whatever they prefer, without being limited by what's available inside the platform natively.
The customer had been reading about Microsoft Fabric's Copilot capabilities and Data Factory integration. They wanted to know whether they could replicate what we'd built using those tools.
Our answer was: technically, yes. Absolutely you could. That's how the conversation started.
The question nobody in that room had considered
It was a Teams call. IT director, programme managers, a couple of operational managers. We talked through how the APIs work, what Q-Bridge actually does under the hood, why we'd built it the way we had.
And then we asked: once it's built, who's going to maintain it?
The call went quiet.
Not awkward quiet — thinking quiet. The concept, it became clear, hadn't really been part of the mental model. The assumption, as best we could read it, was that you build it, it works, and that's more or less that.
So we shared something that we don't mind saying publicly: Q-Bridge barely makes a profit. We have five customers on it. We employ a full-time developer whose job is to maintain it and continuously develop it.
Why would we do that — why would any business do that — if building it once was enough?
What maintaining a live API sync actually looks like
We're using the same Rubixx APIs that customer would be using. The difference is what happens after the first working version exists.
Rubixx is an active, developing platform. They build new endpoints — we adapt. They change a column name or a data type — we adapt. They introduce a bug — we catch it, we raise it, and we adapt around it while it's resolved. Every one of those changes requires development work to keep Q-Bridge running correctly and completely.
Q-Bridge currently syncs over 72 endpoints, creating over 200 tables. That list keeps growing as Rubixx continues to release new functionality.
We also represent the collective voice of all our customers in our relationship with Rubixx. When something isn't working, or an endpoint is behaving unexpectedly, we're not one customer raising a ticket — we're a partner raising it on behalf of multiple customers, with usage data and context that a single organisation couldn't bring to that conversation on its own. That matters.
The multiple hats trap
Back on the call, the conversation moved to what in-house development would actually look like. A developer capable of building and owning something like this — someone who can hit the ground running with APIs, data pipelines, and relational database design — is probably going to cost around £50k a year.
And here's where we see a pattern that's almost universal in the housing sector specifically: the multiple hats assumption. The thinking goes that maintaining the sync will only need a couple of hours a week, so the developer can cover a range of other projects at the same time. Everyone's a winner.
In practice, what tends to happen is that maintenance gradually takes more time than expected. Bugs surface in production. Endpoints behave differently than they did in testing. And if the original build leaned heavily on AI-generated code — which is increasingly likely — diagnosing those bugs isn't always straightforward, because the code may not be as legible or consistently structured as code written to be maintained by a human over time.
Someone else in the call mentioned they'd spoken to a large Housing Association that was running a handful of their own pipelines and seemed happy with it. And our honest response was: that makes complete sense, and we'd endorse it.
If you can be selective — a handful of specific endpoints you genuinely need, a limited and well-understood scope — that's a legitimate and reasonable approach. It's manageable, it keeps maintenance proportionate, and it gives you meaningful control over the data that matters most.
72 endpoints and 200 tables is a different conversation.
The economics, plainly
Software businesses exist because every piece of software requires ongoing development. That's not a bug in the model — it's the entire reason the model works.
When you subscribe to a product, you're not just paying for what it does today. You're pooling your maintenance costs with every other customer on that platform. The subscription revenue funds a team — developers, product managers, support — who think about nothing else but keeping that product running and making it better. Each customer pays a fraction of what they'd pay to replicate that capability internally.
When you build your own solution, you take on that cost entirely. Not as a one-off. As a permanent operational commitment.
That's not an AI capabilities argument. It's business economics.
What we actually said at the end of that call
If you're sitting in a meeting right now where someone has just asked "can't we just build this with AI?" — here's our straight answer:
You can. We do.
But make sure you're asking yourself why others haven't already done it. There just might be a gotcha around the corner.
Sometimes there isn't. Sometimes building it is the right call, and the maintenance commitment is proportionate to the value it creates. We're not trying to talk anyone out of building things — we built something ourselves, and we're glad we did.
We're just saying: go in with clear eyes. Ask who owns it after day one. Understand what the APIs you're depending on actually look like over time. Price in the ongoing cost, not just the build cost. And if the answer to all of those questions still points to building — then build it with confidence.
Ryan Tirrell is the Founder and Director at RTBSS, a technical consultancy specialising in housing system implementations and digital transformation for Housing Associations and Local Authorities across the UK. Q-Bridge is their automated data sync product for Rubixx HMS customers.