Comparison · Build vs buy
Custom build or off-the-shelf: which one an NDIS provider actually needs
Most NDIS providers should buy, not build. Off-the-shelf compliance platforms cover the standard obligations well, and below roughly 30–50 staff the economics almost never favour custom development.
Custom is justified in three situations: your service model does not map onto the platform's data model, you are carrying an obligation the platform does not represent at all, or you are paying for the same integration work every year without ever owning it.
This page is written by someone who builds custom software, which is a reason to read the recommendation against interest. I am telling you to buy in most cases because most custom builds commissioned by providers your size fail on maintenance, not on delivery.
Side by side
| Dimension | Off-the-shelf platform | Custom build |
|---|---|---|
| Upfront cost | Low. Subscription from day one | High. Full cost before any value |
| Time to first value | Days to weeks | Months |
| Fit to standard obligations | Strong. That is the product | Equal, at much greater cost |
| Fit to an unusual service model | Poor. You adapt to the tool | Exact |
| Obligations the vendor does not model | Not represented at all | Represented as first-class |
| Regulatory change | Vendor absorbs it | Your cost, every time |
| Ongoing maintenance | Included | Yours, permanently |
| Data ownership and exit | Depends on contract | Complete |
| Integration with what you already run | Whatever the vendor supports | Whatever you need |
When to buy, and stop reading
- Under about 30 staff, or a single service type.
- Your obligations are the standard NDIS Practice Standards with nothing unusual layered on.
- You have no one internally who would own a custom system after handover.
- Your main problem is that nobody is doing the compliance work. That is a process and staffing problem, and software will not fix it.
If you recognise yourself in that list, the honest recommendation is a platform such as the established NDIS compliance products, and you should not be commissioning custom development. There is no engagement here for me in that case, and saying so is cheaper for both of us than discovering it in month three.
When custom is genuinely justified
Your service model does not fit the data model
Providers running blended or unusual arrangements, such as mixed SIL and SDA, shared programs across participants or complex subcontracting, routinely find the platform cannot represent the thing they actually do. The tell is that staff maintain a parallel spreadsheet to hold the truth the system cannot.
You carry an obligation the platform does not represent
Retention schedules on participant records, consent lifecycle where consent is withdrawn and re-given, evidence-of-control requirements from a funder or insurer. Generic compliance platforms model the Practice Standards; they typically do not model your specific statutory or contractual overlay.
You are renting integration you will never own
If you pay annually for connectors between rostering, finance and compliance, add up three years of that spend before assuming custom is more expensive.
The option most people skip
There is a third answer that is right more often than either extreme: keep the platform, and build the narrow piece it cannot do. A small, well-scoped system that handles your one unusual obligation and integrates with what you already run costs a fraction of a full custom build and leaves regulatory change on the vendor's side.
In practice this is what most of my NDIS work is. Not replacing anyone's compliance platform, but building the specific thing sitting in a spreadsheet next to it.
Common questions
What does a custom NDIS compliance system actually cost?
It depends entirely on scope, and anyone quoting a range without seeing your obligations is guessing. What is knowable up front is whether custom is warranted at all. That is what the two-week review answers, and you keep the output whether or not you proceed.
Can we start with a platform and build custom later?
Yes, and this is usually the right sequence. Run the platform, find where staff work around it, and build against the documented workaround. You get a specification from real behaviour instead of from a workshop.
What happens to a custom system if we part ways?
You should own the code, the infrastructure accounts and the documentation from day one, with no dependency that only the builder can renew. If a prospective developer will not agree to that, that is the answer to whether you should engage them.