Scaling an NDIS Provider Organisation: From 20 to 200 Participants

An NDIS provider with 20 participants runs differently from one with 200. The founder knows every participant, rosters are intuitive, relationships are personal. At 200 participants, that model breaks: the founder becomes a manager, rosters need structure, and relationships become processes. Anticipating that shift is the difference between smooth scaling and a crisis.

Staffing grows non-linearly. A common mistake: assuming that doubling participants means doubling staff. Actually, it means something closer to 1.5x: systems and process maturity mean a larger team is more efficient per capita. But if you don't have those systems in place by the time you're 80 participants, you'll hire blindly and end up with the wrong people in the wrong roles.

Inconsistency becomes visible. With 20 participants, quality is personal: every worker meets the founder, every family gets the same onboarding story, incidents are handled the same way because one person handles them all. With 200, that consistency vanishes unless it's documented. Without written policy, two coordinators will handle the same situation differently, and families will notice.

Rosters stop fitting in a spreadsheet. You can roster 20 participants by hand; by 100, you need software or your coordinator spends 40 hours a week on rosters alone. By 200, without proper rostering software, rosters start failing: gaps, double-bookings, inefficient geography. Switching to proper software at 150 participants is too late; you do it at 70.

Support worker retention becomes a crisis point. A small provider knows every worker, relationships are strong, turnover is low. Scaling fast, turnover spikes: new workers don't bond the same way, training is ad hoc (because it used to be 'show them around'), communication breakdowns happen. Formalising training, mentorship, and team culture before you scale is unglamorous but essential.

Finance becomes opaque faster than you expect. A provider with 20 participants tracks money intuitively. With 200, that breaks: is this funding claim accurate? How much admin is over-budget? What's our real cost per participant hour? If finance is ad hoc, you won't know until the audit fails. Getting real financial systems in place by 50 participants is wise.

Scaling successfully requires building infrastructure before you need it. The founder's instinct is usually to hire staff first (to handle growth), but that's backwards. Build process, documentation, and systems first, then staff has clear expectations and doesn't recreate their own way of doing things. It's a counterintuitive rhythm, but it's what separates 'chaotic growth' from 'planned growth.'