More aged care boards are asking whether to build their own systems. Here is our honest view, including when the answer is yes.
In the past two years, compliance has rewritten what aged care providers need from their systems. Care minutes, AN-ACC reassessments, Support at Home and the new Aged Care Act have each added data, workflows and deadlines. Frustrated with vendors who were slow to keep up, some executive teams have reached a simple conclusion: "We'll build it ourselves."
We should be upfront. We build aged care software, so you'd expect us to argue against that. We're going to make the case anyway, because we've seen what keeping a compliance-critical platform current actually involves. But we'll also tell you when building is the right call, and what to demand from any partner if you don't.
When building makes sense
Building isn't always wrong. It can be the right choice when what you're building is genuinely unique to how you operate and gives you an edge no product on the market offers. Examples include a specialised care model, a bespoke board dashboard, or analysis that combines your operational data with sources only you hold.
It also needs a provider with the scale to fund a permanent team, not a project. The common thread is that the thing being built sits on top of the core systems. It doesn't replace them.
What keeping up really takes
The build is the part everyone budgets for. The cost that catches organisations out comes after launch. Software engineering research finds maintenance typically accounts for 40 to 80 per cent of a system's lifetime cost, averaging around 60 per cent. Most of that goes on adapting software to change, not fixing bugs (Glass, Facts and Fallacies of Software Engineering).
In aged care, change is constant. We support more than 90,000 residential beds and maintain their connections to Medicare and Services Australia, so we see every rule change land. The new Aged Care Act, the strengthened Aged Care Quality Standards and Support at Home have brought a steady run of changes to funding, claiming and reporting, often with tight timeframes and detail that keeps shifting right up to go-live. Each one has to be understood, built, tested and released before the deadline, without disrupting the providers who rely on it.
A provider building in-house carries all of that alone, and has to absorb every change without slowing down care. That means engineers, testers, a security program and a direct line to Department updates, funded every year, not just in the year of the build.
Partner for the core, build at the edges
Build or buy is a false choice. The approach we see working best is a mix of both.
The core is everything that has to be right for funding and compliance: claiming, AN-ACC, care minutes, rostering against award rules, and government connectivity. Get the core from a specialist whose whole job is keeping it current.
The edges are what makes you different: the dashboards your board wants, the analysis behind your strategy, and the workflows unique to your care model. Build those, if you want to, on top of open data from the core. That way your engineering effort goes into what sets you apart, not into keeping up with the latest Department change.
What to demand from any partner
The most common reason providers consider building is fear of lock-in, and historically that fear was earned. Legacy systems kept data behind walled gardens, and getting it out was slow and expensive. You shouldn't accept that today.
Whoever you partner with, your contract should make clear that you own your data and can take it with you. Your data should be hosted and governed in Australia, under Australian law. There should be documented APIs and data access, so you can connect other systems and build at the edges without asking permission.
If a vendor can't offer those three things, building may look attractive for the wrong reasons. The better answer is a different partner.
Five questions before you approve a build
Before any build reaches the board for approval, we'd suggest management can answer these:
- Is this core or edge? Does it touch funding, claiming or compliance, or is it something unique to how we operate?
- Who keeps it current? Have we funded a permanent team for the life of the system, not just the build?
- What happens when the rules change? Who reads the Department's updates, and how quickly can we ship a change?
- Who owns the risk? If a claim is wrong or a report is late because of our software, are we comfortable carrying that ourselves?
- What are we not doing instead? Which care, workforce or growth priorities lose leadership time while we run a software project?
If the answers are clear and the item is edge, not core, building may be the right decision. If not, the money is probably better spent on the right partner.
Spend your effort where you're different
No provider sets out to become a software company. Yet the build-it-ourselves path can lead there quietly, one compliance change at a time.
Our view is simple: let specialists carry the core, keep your data open and in Australia, and put your own energy into what makes your care distinctive. If you're weighing a build decision now, we're happy to talk it through with you, even if the answer turns out to be building it yourself.
