Comparison · Three options, not two
NDIS software: build, buy, or configure what you already have?
Most providers should configure before they buy, and buy before they build. The third option is the one usually skipped, and it is right more often than either extreme.
Build only when your service model cannot be represented in the platform's data model, when you carry an obligation the platform does not model at all, or when you are renting integration you will never own.
| Configure | Buy | Build | |
|---|---|---|---|
| Cost | Lowest, staff time only | Subscription | Highest, all up front |
| Time to value | Days | Weeks | Months |
| Fit to standard obligations | Depends on the platform | Strong | Equal, at greater cost |
| Fit to an unusual model | Poor | Poor | Exact |
| Regulatory change | Vendor absorbs | Vendor absorbs | Your cost, every time |
| Ongoing maintenance | None | Included | Yours, permanently |
| Exit | Same as buy | Depends on contract | Complete control |
Start by configuring, because it is nearly free
A surprising share of "the platform cannot do this" turns out to be "nobody has been through the settings since implementation". Custom fields, workflow rules, notification schedules and report templates cover more ground than most providers realise, and the person who set the system up has often left.
Before scoping anything, take the single loudest complaint about your current system and establish whether it is a configuration limit or a structural one. That distinction is cheap to determine and expensive to skip.
Buy when your obligations are the standard ones
- Under about 30 staff, or a single service type.
- Obligations are the standard Practice Standards with nothing unusual layered on.
- Nobody internally would own a custom system after handover.
- The real problem is that the compliance work is not being done, which is a staffing and process problem software will not solve.
If you recognise yourself in that list, buy an established platform and do not commission custom development. There is no engagement in it for me, and saying so now is cheaper for both of us than discovering it in month three.
Build only against these three signals
The data model cannot hold your service model
Mixed SIL and SDA, shared programs across participants, complex subcontracting. The tell is a spreadsheet maintained beside the platform, holding the relationship the platform has no field for.
You carry an obligation the platform does not model
Retention schedules on participant records, consent that is withdrawn and re-given, evidence-of-control requirements from a funder or insurer. Platforms model the Practice Standards. They generally do not model your specific statutory or contractual overlay.
You are renting integration permanently
Add three years of connector and integration spend together before assuming custom is the expensive option.
The hybrid that is usually correct
Keep the platform for the standard obligations. Build the narrow piece it structurally cannot do, integrated with what you already run. It costs a fraction of full custom, and it leaves regulatory change on the vendor's side where it belongs. In practice this is what most of my NDIS work is.
Common questions
How much does custom NDIS software 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, which is what a two-week review answers.
Should we replace our compliance platform?
Usually no. Replacing a working platform is expensive and risky, and the gap is normally narrow. Building the narrow piece and integrating is the cheaper and more reversible move.
What if we build and then want to leave?
You should own the code, the infrastructure accounts and the documentation from day one, with no dependency only the builder can renew. If a developer will not agree to that, you have your answer about whether to engage them.