AI is making software easier to build, but does that mean aged care providers should build more themselves? Or does it change what they should expect from their technology partners?
An engineer at almost any company can now pick up a coding agent and build a prototype that meets the company’s specific needs. Then, they can iterate on feedback and deploy a bespoke tool that potentially provides more value than a generic SaaS platform – at a fraction of the traditional development cost.
The SaaS “build versus buy” debate is a tale as old as time. But something genuinely has changed.
It would be disingenuous not to acknowledge that the do-it-yourself case has suddenly become very attractive and has substantially reopened the conversation.
Without a doubt, the build argument is now viable, and we’re already seeing this happen in the Australian aged care sector with the AI platform Buddy.
The benefits are obvious. A DIY solution can be purpose-built for your organisation, your specific sector issues and your users. With AI assistance, it can potentially be created within remarkably short timeframes, allowing providers to solve immediate problems faster and, at least initially, more cost effectively.
Only a few years ago, software development faced significant barriers: developers, time, money, and specialist expertise. Now you may not even need a software engineer to create a bespoke prototype, iterate quickly and seemingly deliver something more tailored than generic SaaS.
What has changed is the economics and accessibility of “build”.
But even though one side of the argument has become much stronger, that doesn’t mean the debate is over, or that you should rush to cancel your existing vendor contracts.
There are circumstances where it makes sense to build your own solution – but only if you also understand the trade-offs.
Building software is not the same as operating software
AI has dramatically reduced the cost and time involved in building code. However, it hasn’t reduced the responsibility that comes with operating it securely, safely, robustly and reliably.
The initial build was never the whole cost of software.
There are long-term implications:
- Maintenance
- Changing architecture
- Support
- Changing sector requirements, and
- Potential future reform.
Code and the servers it sits on require constant updates and security patches. Organisations must manage their data, reduce operational risk and close the considerable gap between a prototype and production-grade reliability.
Authentication, infrastructure, permissions, security, compliance, deployment and production reliability can ultimately take considerably more effort than creating the initial application itself.
The fact is that software is never done.
So before electing to DIY, consider some fairly basic questions:
- What happens when it fails at 2 am?
- Who maintains it after the person who created it leaves?
- Who tests changes?
- How is access controlled?
- Where does resident information go?
- How are regulatory changes accommodated?
- Who is accountable when the software gets something wrong?
- What happens when you need to scale it?
- Is there a point where it becomes more trouble than it is worth?
These questions matter in any organisation. In aged care, they become particularly consequential.
In Australia, the sector has explicit obligations around privacy, data, security, and governance. Organisations frequently insist that their software vendors meet defined security and compliance standards such as SOC 2 and ISO 27001.
But if you build your own solution, are you applying the same standards to yourself?
An impressive prototype may demonstrate that something can be built. But that’s not necessarily evidence that it’s ready to become part of critical operational infrastructure.
Buying software has always meant buying more than code
An aged care organisation buying an established platform isn’t simply paying for screens and functionality. It’s also buying maintenance, accumulated knowledge, testing, security, reliability, implementation expertise, support, regulatory and domain knowledge, and the responsibility for keeping the product working.
As the creation of code becomes easier, these less visible parts of software become proportionately more important, not less.
A bespoke application produced quickly with AI may appear to perform the same task as an established product. But the visible application is only one part of what is required to deliver and sustain operational software.
That still provides a powerful argument for “buy”. But before the software industry becomes too comfortable with that conclusion, there’s another side to this debate.
SaaS vendors are not off the hook
The threat is real, but perhaps not for the reason people think. Aged care providers need to reconsider build versus buy, but software vendors also need to reconsider exactly what they’re selling.
The fact that an established vendor has accumulated functionality, infrastructure, security, domain expertise and years of intellectual property doesn’t mean its product is automatically suited to the next generation of technology.
Vendors need to reinvest in their software and rethink products that were designed for a previous era. Genuine reinvention may be required rather than simply pasting an agentic or AI interface over an existing product.
Rethinking the purpose of the process and asking whether a module/function or feature needs to exist at all is something quite different.
That may mean tearing up how the product works, reconsidering workflows, how it’s priced, how it’s sold, and ultimately what the organisation delivering it looks like on the other side. The smarter software vendors will already have started that reinvestment and reinvention.
What should the next generation of aged care software actually look like?
This is where the aged care argument becomes more interesting than either extreme of the traditional build-versus-buy debate.
AI genuinely changes what can be built and by whom. At the same time, aged care makes reliability, governance, security, accumulated domain knowledge and accountability unusually consequential.
AI-native software shouldn’t merely reproduce today’s screens faster, it should: remove unnecessary navigation, automate parts of workflows, interpret information, surface what matters, allow staff to interact using natural language, and genuinely reduce administrative burden.
Software vendors have for decades “sold” aged care organisations on reducing administration and compliance burden and, of course, have strived to do so. AI now creates the potential to take that promise considerably further.
Multi-step workflows and approvals are particularly exposed to disruption because AI can increasingly assist with interpretation and decisions that previously required people to navigate multiple screens, locate information, and manually move a process from one stage to another.
The opportunity isn’t simply to bolt AI onto the software we already have, but to ask: what would we design if we were starting again today?
Returning to build versus buy
Which brings us back to the original question of “should we build or buy?” Taking the above into account, it’s more beneficial to ask: “What technology capability should we own? What should we entrust to specialist providers? And where should AI change that boundary?”
Build can make sense where something is genuinely differentiating or uniquely specific to the organisation. Whereas buy can make sense for capabilities where maintenance, reliability, security, regulatory knowledge, and ongoing resource demands outweigh the benefit of differentiation.
Increasingly, the answer may also be neither purely “build” nor “buy”.
I suspect that the future will involve configurable platforms, APIs, AI services, and specialist vendors working with providers to create much more tailored experiences.
In other words, AI may not eliminate the relationship between aged care and software vendors, but it may just change the division of responsibility between them.
AI isn’t killing software; it’s changing where its value resides
Recently, there have been alarming headlines declaring that “SaaS is dead”. These ought to be viewed as indicators of something important: the nature of what makes software valuable is changing quickly – very quickly.
For the last decade, SaaS companies could often differentiate themselves through a somewhat better interface for a human workflow. That alone is becoming increasingly difficult to defend.
For aged care technology, that value increasingly sits in trusted data, domain knowledge, integration, security, governance, reliability, accumulated experience and genuinely better ways of working.
Existing vendors in the care sector retain advantages, particularly where they operate systems of record or support mission-critical operational processes. But incumbents are not invincible. The fact that a weekend project using a coding agent is unlikely to replace a mature enterprise platform doesn’t protect that platform forever.
Established vendors have a different challenge: they need to make sure the advantages accumulated over many years don’t become an excuse for standing still.
The lessons
For aged care leaders, don’t assume that because AI can create something impressive quickly, it’s automatically ready to become critical operational infrastructure. There will increasingly be good reasons to build some capabilities yourself. But the decision needs to consider the lifetime responsibility for that software, not merely how quickly and cheaply the first version can be created.
For aged care technology vendors, don’t assume that decades of accumulated functionality will protect you. If AI enables genuinely simpler and better ways for people to work, incumbency isn’t enough. Vendors should be asking themselves: if a team powered by AI rebuilt our flagship product today, what would they build, and what would they leave out?
For some, the answer may require rearchitecting products from the ground up for a genuinely AI-native future. And for both providers and vendors, the real opportunity isn’t deciding whether AI destroys SaaS, it’s reconsidering what technology should do for aged care in the first place.
