SISO · Internal analysis · 10 September 2026

Can open source do 90% of the Aged Care Module?

A reuse reality check against the four-page Unicare “Support at Home” proposal quoting USD 30k / 40k / 50k across 8 / 12 / 14 weeks.

The arithmetic

The proposal lists 32 quoted feature lines. Here is how many have a credible existing source behind them.

Where reuse is real

One repository does most of the useful work: neighborhood-lab/folk-care. It is a cohesive React / TypeScript + Express + PostgreSQL care slice with care plans, clients, caregivers, visits, medications, incidents, clinical notes and billing already wired together. Its billing code has genuine rate lookup and invoice mechanics. That is a real head start on the care loop.

Where reuse is a fantasy

Everything that makes this an Australian aged care product has no donor. This is the entire commercial half of Package 2.

Three things that undercut the reuse story

1. Nothing has been run

All 17 repositories are marked runtime_verified: false. No install, no migration, no runtime test, no security audit. Source inspection tells you a file exists; it does not tell you the thing boots, or that its tests pass, or that its authorisation holds.

2. The lead donor has a security hold and a licence contradiction

folk-care builds actor context from X-User-* HTTP headers — meaning the caller asserts who they are. It also uses floating point in billing, which must never become the authority for a funding ledger. Its LICENSE file says AGPL v3-or-later while GitHub's metadata reports NOASSERTION. That combination has to be resolved before a single line ships, because AGPL carries real distribution obligations.

3. Popularity is not fitness

The high-star repositories in the list are the ones you would not use. Docling has 66k stars and is a deferred OCR parser. ERPNext has 39k and is a full ERP — installing it to hold a participant budget table would be an act of self-harm. The genuinely relevant care repositories have 15 stars and 0 stars respectively.

So what do we actually need to know?

Two of these are hard blockers. Nothing serious can be priced or promised without them.

1. The Aged Care Module Scope Specification v1.0, dated 05/09/2026. The quote names this document as its own source. We have never seen it. Without it, all 32 lines are module names with no field-level definition of done — which is precisely the gap a development shop bills against and then argues about at delivery.
2. Read access to the existing Unicare platform. The proposal says “add this module into our Unicare platform.” Whether the right answer is extend, integrate or replace depends entirely on what is already there. A read-only clone, or at minimum API documentation plus a demo login.
3. Which package is actually being bought. Package 1 excludes budgets, claims, contributions, statements, assistive technology, home modifications, standards, evidence, offline and mobile. That is a fundamentally different product from Package 2, and the reuse maths above changes completely between them.
4. Is claim submission a direct integration or a CSV export? These are not remotely the same commitment. An export must never be described as a submission receipt.
5. What does “Finance Module” mean? A funding subledger with an accounting export, or full general ledger and payroll? The gap between those two readings is worth more than the discount on offer.
6. Who signs off the Australian rules? Named human accountability for funding calculations, contribution splits, SIRS reportability and restrictive-practice records.
7. Does Package 3’s mobile app require offline? Offline is explicitly excluded from Packages 1 and 2 and never explicitly added to Package 3. Full offline sync is not a feature; it is a project.

The recommendation

One caution worth restating: the earlier provider-registration research and this care-operations product are two different products. An applicant company is not a care participant. Merging them would quietly double the scope and confuse both.