Should You Build Your Own Care Management System?

There is nothing wrong with having an ambition.

If you want to build a care management system because you have spotted a real problem in care and nobody has solved it properly, go for it. Some of the best things in this sector were built by people who were fed up with the tools they had been given. Careberry started that way, too: in a small home care office in Buckinghamshire in 2017, because I couldn't find a system that understood how a real rota falls apart on a Tuesday morning.

But the first step is not to open a laptop. The first step is to look around and see whether someone has already solved it. Book six demos. Ask hard questions. Ask to see the ugly bits, not the sales deck. If after all that the problem is still unsolved, then yes, build it. The sector needs people who build.

What worries me is a different conversation, one I have had four or five times in the last 12 months. A provider tells me they have found a small team overseas that will build them their own system using AI in eight weeks, for a fraction of what they are paying now. They are not building it to solve a problem. They are building it to save money.

I am not speculating about how that ends. Over the past few months I have spoken with three providers who paid to have their own system built and then walked away from it. Between them, they had spent thousands of pounds and kept nothing. One of them, by his own account, spent over a million.

Not one of them set out to waste that money. Every one of them was told it would be cheaper.

So let me write out the recipe. Not to be discouraging. To be honest about what is in the bowl.

Step one: analysis,and the part nobody enjoys

Before a single line of code, you need to write down what the system must do. Not "rostering". That is a word, not a requirement. You need to specify what happens when a carer calls in sick at 6.40 am and three calls need reassigning to someone who is off but is available to cover sickness. What happens when a client goes into hospital for nine days? What happens when a carer works across two branches on different pay rates? What happens when a medication is refused, and who is told, and how fast, and what the audit trail looks like when the inspector asks six months later?

In our own build, the medication module alone had some two hundred rules before it was safe to ship. Care is not complicated because the software is complicated. It is complicated because people are, and care service is heavily process-driven and regulated.

Expect this phase to take months, and expect someone who has actually run a service to do it. A developer cannot write these rules. Only you can, and you have a service to run.

Step two: architecture, and the ten-year question

Now you decide the shape of the thing. Single database for all your branches, or one per branch. How you handle a carer who has three roles. How you handle permissions.That one sounds boring until an inspector asks how you know an employee who handles billing doesn’t have access to clients' care plans.

The question that matters here is not "does it work?" It is "will it still work when we have five times the data?" Systems built for one provider almost always assume a shape that stops being true the moment you grow, take on a council contract, or buy another branch.

Step three: choosing your programming languages, and who will still know them

This is where the long-term risk hides. Pick a language and framework that will still be maintained, and still have developers available, in 2036. Then ask the harder question: if the two people who built this walk away, can anyone else pick it up? Is it documented? Is it in your repository or theirs? Do you own the code, or a licence to it?

You don’t want to be left with a functioning system, only to find that, a few years later, no one on Earth understands it. This issue transcends IT; it is an existential problem.

Step four: the database

Your database holds medication records, safeguarding notes, care plans, next of kin details. Special category data under UK GDPR, the most sensitive tier there is. So: how often is it backed up? Where do the backups live? Have you ever restored one? A backup you have never tested is not a backup; it is a hope. And when a family exercises their right of access, can you export everything you hold on that person, in a readable form, within a certain time?

Social care records generally need to be retained for years after the last entry. Your database needs to survive longer than your developer's contract.

Step five: hosting,servers and where in the world your data sits

You need UK data residency. Not "the developer lives in the UK". The actual servers and backups must be in the UK. Then you need redundancy, because a single server in a single data centre will go down. Then monitoring, because you need to know it went down before your carers do at seven in the morning.

Then you need someone to patch it. Operating systems, libraries, dependencies. A system left unpatched for eighteen months is not a system; it is an incident waiting for a date.

Step six: mobile apps,and the App Store you do not control

Your carers need an app. That is two builds, iOS and Android, plus a family app if you want families engaged. Each one needs to work offline, because many homes your carers visit have no signal in the back bedroom, and it needs to sync sensibly when signal returns without duplicating notes or losing them.

Then Apple and Google update their operating systems every year and things break. You need someone to fix them, quickly, forever. Not once. Forever.

Step seven: security, and the certificates that prove it

TLS certificates that renew automatically, because an expired one takes the whole system down on a Sunday. Encryption at rest and in transit. Multi-factor authentication, ideally passkeys rather than SMS codes. Geo-fenced clock-in if you want it. Role-based permissions that actually hold.

Then you need proof, because "we take security seriously" is not evidence. That means penetration testing by an independent firm, at least annually, and remediation of what they find. Cyber Essentials Plus. Many commissioners will expect ISO 27001, which is not a certificate you buy. It is a management system you run, audited, year after year.

Step eight: ICO registration and the paperwork that becomes your job

You must register with the Information Commissioner's Office and pay the data protection fee:currently £52 for micro organisations, £78 for small and medium ones, and £3,763 at the top tier. That part is cheap. What is not cheap is everything registration implies: a Data Protection Impact Assessment for the system, a lawful basis for every processing activity, records of processing, a breach procedure you have rehearsed, and someone accountable for all of it.

Here is the part providers miss. When you buy a system, your supplier is the processor and carries much of that weight. When you build your own, you are the controller and the processor. Every breach is yours. Every question from the ICO lands on your desk.

Step nine: the DSPT,and everything that sits behind it

The Data Security and Protection Toolkit is the NHS assurance standard the care sector is measured against. For many providers it is effectively required: anyone accessing personal information held by the NHS, anyone on an NHS Standard Contract, and increasingly anyone whose council or Integrated Care Board asks for it. You will need "Standards Met", and you will need to evidence it: access controls, device management, supplier contracts, tested backups, breach logs, staff training your team can explain rather than just tick. And above all, an independent auditor must audit it, which will cost you a few grand per year.

If you want your system to talk to the NHS, to GP Connect, to the Personal Demographics Service, to shared care records, the bar rises again. Supplier assurance, connection agreements, technical conformance.

There is also clinical safety. Digital systems used in health and care are expected to meet DCB0129 if you manufacture them and DCB0160 if you deploy them. If you build your own, you are both. That means a named Clinical Safety Officer, a clinical risk management file, and hazard logs maintained for the product's life.

Step ten: QA, testing and proving it works

Then you test. Not "we clicked around, and it seemed fine". Automated test suites so a billing change doesn't silently break the MAR chart. Regression testing before every release. User acceptance testing with real carers, who will use it in ways you never imagined. Accessibility testing, because some of your workforce needs larger text and screen readers. Load testing, because the pressure on the system on Monday at 7am is not the same as on Wednesday at 2pm.

Step eleven: the one that never ends

Everything above gets you to launch day. Then you own it.

Regulations change. Minimum wage thresholds change in April, and your payroll logic changes with them. Someone has to make those changes, test them, and ship them before the deadline, every single year.

And at 1am on a Saturday, when the app will not let a carer sign in for a medication visit, someone has to answer the phone. Who is that? Is it the developer overseas, asleep, in a different time zone, on a contract that ended in March?

The maths people do not do

The true cost of building your own system isn't just the initial development; that's merely the deposit. The real expenses come from the ongoing mortgage, which includes retaining a developer or small team permanently, hosting, backups, annual penetration testing, renewing Cyber Essentials and ISO certifications, gathering evidence for the Data Security and Protection Toolkit (DSPT), ensuring clinical safety governance, maintaining the app on the App Store, and dedicating a portion of your registered manager's time for the foreseeable future.

Regardless of your organisation's size, associated running costs can total thousands of pounds. You can do the maths: should you bear all these costs and headaches, or would it be wiser to source a well-managed system for a fraction of that expense and concentrate on what you do best: providing high-quality care?

I have watched providers spend more on maintaining a system they built than they would have spent on an established platform, and end up with less. Fewer features. No family app. No compatibility matching. No NHS interoperability. No update arriving every two weeks. And a single point of failure with a human name attached.

The saving that was never there

Here is the part I find hardest to explain.

Some of the providers who tell me they are building their own system to cut costs are already on our lowest price band. They are paying us less than a month of one carer's overtime. And they are proposing to replace that with a developer, a server bill, a penetration test, an ISO auditor, a Clinical Safety Officer and a decade of responsibility that never lifts.

The saving they are chasing do not exist. It never did. What they would actually be buying is a second job, and it has no annual leave.

The email that told me everything

A few months ago, a provider wrote to us with a request that has stayed with me.

They asked us to set up a student as an administrator on their account, so that he could learn how the system worked and help them build their own version of it.

I do not believe there was any malice in it. I think they simply had not thought it through. But read that request again, because it contains two serious problems in one short email.

The first is data protection. An administrator account in a care management system can see care plans, medication records, safeguarding notes, next of kin details and staff records. Handing that access to a student with no employment contract, no DBS check, no training, and no lawful reason to see any of it is not a shortcut. It is a personal data breach. And it is your breach, because they are your clients and you are the controller.

The second is copyright. Software is a protected work. Studying a licensed system to reproduce it is not research; it is copying, and it falls outside what any licence agreement permits. It would also have ended their access to ours.

We declined the proposal and explained our decision. I hope our response was understood as intended.

The risk that cannot be costed

Software you can rebuild. Reputation you cannot.

If the system you built loses a week’s worth of care notes, the CQC (Care Quality Commission) doesn’t want to hear about your system’s architecture. If a data breach exposes the medication records of forty vulnerable individuals, the local newspaper won’t print your explanation. If a family discovers that their mother's care plan was stored on an unpatched server somewhere in the world, simply because it was cheaper, no amount of savings can justify the consequences that follow.

Trust in care is built over years but can be shattered in an afternoon.

Where Careberry sits in this

I am not neutral here, and I will not pretend to be. But I would say this even if I sold nothing.

Careberry was built by a care provider for care providers. We delivered over 60,000 hours of care in-house before we ever sold the product, so the rules come from real shifts rather than a workshop. We are bootstrapped, profitable, and we ship updates every two weeks. Care planning, rostering and travel optimisation, eMAR and medication levels, recruitment and onboarding, compliance and dynamic audit, carer-to-client compatibility matching, two native apps, GP Connect, passkeys and single sign-on, offline mode, and role permissions that let one login carry multiple roles across branches.

Everything on that list is something you would otherwise have to build, test, secure, certify and maintain yourself. Forever.

The important thing to understand isn't whether you can build it, but the true cost involved. It's not just about the initial invoice; it's about the years of ownership that follow. It takes strong determination to make things work, and you should be ready for many sleepless nights managing updates in the small hours, as well as the inevitability of failure at some point.

A closing thought

People first. Process next. Technology always.

If your ambition is to solve a problem in care that nobody has solved, build it, and tell me about it. I will help where I can. But if your ambition is to run a better care service, then the best use of your money is not building software. It is putting it back into the people doing the visits, and letting someone else carry the pager.

Your job is care. Let the platform be somebody else's job.

Book a viewing of Careberry and let us show you what a decade of that ownership looks like, carried by us and not by you.

‍