Sydney Disability Support
An NDIS service platform on iOS and Android. Participants book support, workers run the shift, and the same record carries through to notes and invoices.
Sydney Disability Support
Australia
Flutter Developer (Contractual)
Cuebites · Production
Cross-Platform Flutter Engine
Registered NDIS provider · live on the App Store and Google Play
One Flutter app published on the App Store and Google Play
Participants, support workers, and administrators share a lifecycle
Discovery through shift, notes, and invoice stay on the same booking
Request, view, and check status stay obvious for people who need support
Executive Summary
Sydney Disability Support connects people who need disability support with qualified workers. It is a production app on Android and iOS, built for the Australian NDIS sector. The job was not a booking form. A service has to move from discovery to staff assignment, the shift itself, work notes, an invoice, and payment. Every stage has to stay on the same record.
I built the mobile flows at Cuebites across that lifecycle: participant booking, worker registration and profiles, calendars, clock-in and clock-out, shift notes, and the invoice that follows the shift. Firebase backed the app. The interface had to stay simple enough for people with different access needs while still holding client, worker, and administrator workflows in one product.
An AI chatbot sits beside ordinary navigation, so someone who finds menus difficult can still reach booking by conversation. Administrators review staff documents, submitted work, and invoices. The phone app is where the service is requested, delivered, and closed.
The Challenge
The Challenge: One Accessible App for a Whole Support Lifecycle
Support coordination usually splits across finding a worker, checking qualifications, scheduling, tracking the shift, writing notes, and producing an invoice. Those steps fall apart when they live in different tools, and a conventional consumer UI is the wrong shape for people using NDIS supports.
The Booking Was Not the Product
A request is the start. The system still has to match a worker, schedule the visit, let them clock in, collect notes, and produce the information payment depends on. Those stages have to stay synchronized.
Accessibility Had to Carry the Complexity
Participants may have different access needs. Primary actions (request a service, see what is booked, check status) had to stay obvious. The workflow behind them is not simple.
Three Kinds of User, One App
Participants book and track. Workers keep a profile, certificates, a calendar, and a shift. Administrators validate documents, work, and invoices. Each role needs a different surface on the same service record.
A Shift Has to Become an Invoice
Clock-in is gated by place and time. Clock-out waits on a progress note. That record is what the invoice is built from, so delivery and payment are not separate stories.
Project Scope
Engineering Objectives & Delivery Scope
- Ship one Flutter app on iOS and Android for participants and support workers.
- Keep primary actions easy to find: request a service, view services, and check status.
- Support booking for yourself and the service catalog participants actually use: daily living, community participation, skills, transport, accommodation, and plan coordination.
- Show plan budget and utilisation so a participant can see what is available, spent, and pending.
- Give workers a profile, availability, service area, and a personal schedule of assigned shifts.
- Gate clock-in on being nearby and on time, and require a progress note before clock-out.
- Turn completed shift information into an invoice the worker can review and send.
- Hold client, worker, and administrator steps on one service lifecycle, including an AI chatbot as another way into booking.
Engineering Foundation
Architecture & Technical Design
Flutter owns the participant and worker experience. Firebase is the backend. Role decides which surface you see, but the service record is shared: a booking, an assignment, a shift, notes, and an invoice are stages of one object, not separate apps.
One Lifecycle
Discovery, request, assignment, schedule, clock-in, notes, and invoice stay attached to the same service so status on the home screen and status in the worker’s tasks are not two sources of truth.
Role-Specific Surfaces
Participants get request, services, status, and plan. Workers get tasks, a day schedule, clock-in, notes, and invoices. Administrators validate documents and submitted work against that same record.
Shift Constraints
Clock-in stays disabled until the worker is nearby and the shift is due. Clock-out stays disabled until a progress note exists. The shift cannot be closed as an empty timestamp.
Delivery to Payment
Start time, end time, status, and the progress note are the inputs the invoice is built from. Sending the invoice is the last mobile step, not a separate finance tool.
Screen Walkthrough
The product, in the order a user moves
Production screens from the live apps, framed as a journey rather than a pile of captures. Follow them from the first screen to the last action.
Follow the journey →
Deep Dive
Key Technical Implementations
Detailed breakdown of core features addressing complex mobile engineering requirements.
Few Actions, Easy to Find
The NDIS constraint on the interface
The home screen does not open into a dense menu. Request a service, view services, and check status are the whole first screen when nothing is booked. That is deliberate. People using the app may have different access needs, so the primary path has to be obvious before any of the later workflow shows up. An AI chatbot is the other way in, for someone who would rather ask than tap through screens.
- Request, view, and check status as the first actions
- Empty state explains the next step instead of showing a blank list
- Chatbot as a conversational path into the same booking system
From Catalog to a Dated Request
Discovery is part of the service record
Participants browse the supports SDS actually provides, then submit a request with the type, a description of what they need, the date and time, and the location. After that, home stops being an empty state and leads with the next scheduled service. Status tabs keep scheduled, pending, declined, and completed from collapsing into one list.
- Catalog of NDIS support categories, not a single generic booking
- Request captures need, schedule, and place together
- Home and status both read the same upcoming service
The Plan, Not Only the Visit
Budget and utilisation beside the booking
A support request sits inside a funded plan. The plan screen shows what is available on a category, what has been used, and the overall budget: spent, pending, remaining, and how the week is tracking. Participants can see the money and the visit in the same app.
- Category balance with used and available amounts
- Overall budget, pending, and remaining in one table
- Weekly use so the plan is not a document outside the app
Participant View and Worker View
Same service, different job to do
A participant looks at status and the next visit. A worker looks at tasks, a day schedule, and a profile that records who they are, when they are available, and where they work. Matching is meant to use that information (availability, distance, ratings, qualifications) rather than handing the job to whoever is free first. Administrators review certificates and submitted work before a worker is eligible.
- Worker schedule built from the same assigned services
- Profile holds availability and service area for matching
- Administrator review sits on registration, certificates, and submitted work
Clock-In That Knows Place and Time
A shift is not a button you can press early
On the service, clock-in stays disabled until the worker is nearby and the start time has arrived. Once the shift is underway they record start and end, set the status, and write a progress note. Clock-out stays disabled until that note exists. The note is part of the delivery record, not an optional comment after the fact.
- Clock-in blocked until the worker is nearby and the shift is due
- In-progress status with editable start and end times
- Progress note required before clock-out unlocks
The Shift Becomes the Invoice
Payment uses what was actually delivered
Create invoice sits on the same service as the shift. Line items, who it is to, and who it is from are reviewed in the app and then sent. Administrators still validate invoices and payment. The mobile job is to make sure the invoice is generated from the shift, not typed into a second system from memory.
- Invoice opened from the completed service
- Line items reviewed before send
- Admin validation remains the gate on payment
Hurdles & Solutions
Technical Challenges & Trade-Offs
Real production obstacles overcome during engineering and deployment.
A full support lifecycle had to stay understandable for NDIS participants
Kept the first screen to three actions, and only introduced schedule, plan, and status once a service existed. Added a chatbot as another way to reach booking.
The complex path is still there. It does not meet the user on the first tap.
Participants, workers, and administrators need different tools on one service
Split the surfaces by role: home and plan for participants, tasks, calendar, and shift for workers, while keeping one service record underneath.
Status, schedule, and invoice describe the same booking instead of three copies of it.
Staff assignment is more than “who is free”
Worker profiles carry availability, service area, and the documents administrators verify, so matching can use qualifications and distance as well as the calendar.
Eligibility and schedule are both part of who can take a service.
A clock-in with no constraints does not prove a shift happened
Disabled clock-in until the worker is nearby and it is time, and disabled clock-out until a progress note is saved.
The timestamp and the note are required together before the shift can close.
Invoices drift when they are rebuilt from memory after the visit
Attached invoice creation to the service that already holds the shift times, status, and notes.
What gets sent for validation is the delivery record, not a separate spreadsheet.
Outcomes
Impact & Production Outcomes
Sydney Disability Support is in production as an NDIS app, not a booking demo. Participants can find a support, see the next visit, and read their plan. Workers can only start a shift when they are there, and they cannot finish it without a note. The invoice is the last step of that same service.
Published on the App Store and Google Play
Request, schedule, shift, note, and invoice stay together
Each role sees the part of the lifecycle they have to act on
Place, time, and a progress note before the shift can finish
Technology Breakdown
Tools, Frameworks & Libraries
Categorized technical stack employed to achieve reliability, performance, and store compliance.