An offline-first mobile app for children who cannot rely on a connection
A Flutter support tool for autistic children and their caregivers — communication, emotion learning, predictable routines, and explainable progress tracking.
- Client
- A specialist care-technology developer
- Services
- Mobile development, Web development
- Stack
- Flutter · Dart · Firebase · Firestore
The problem
The app supports autistic children and the people who care for them: communication, learning to recognise emotions, predictable routines, sensory regulation, and progress a caregiver can actually understand.
Its users cannot depend on a network connection, and a loading spinner mid-routine is not a minor inconvenience — it breaks the predictability the whole tool exists to provide.
It handles data about children, which sets the security bar high and makes careful scoping an ethical requirement, not just a professional one.
How we approached it
Offline-first from the first commit, not added later. The app works fully without a connection and reconciles when one returns.
We scoped what the product deliberately is not: it is not a diagnostic, screening, or treatment tool, and it says so plainly. Being explicit about limits is part of building responsibly in this space.
Security decisions are justified in the code itself. Where a dependency handles something sensitive — hashing the caregiver PIN, for instance — the reason it was chosen sits next to the choice.
What we built
Offline-first architecture
Full functionality with no connection, with reconciliation on reconnect. The predictable behaviour these users need.
Caregiver access control
A hashed PIN gate separating caregiver settings from the child's experience, so the interface stays simple for one user and complete for the other.
Explainable progress
Progress tracking a caregiver can read and reason about, rather than an opaque score.
Localisation and test coverage
Built for multiple languages from the start, with measured coverage and a written handover pack.
Decisions worth explaining
- 01
Offline-first as an architectural constraint
Deciding this on day one shaped the data layer entirely. Retrofitting offline support into an online-first app is close to a rewrite.
- 02
Naming what the product is not
Stating clearly that it is not a diagnostic or treatment tool protects the users, the client, and the product's credibility.
- 03
Security rationale written inline
The next developer sees why a choice was made, not just what was chosen — which is what stops a well-intentioned refactor removing a safeguard.
Have a problem shaped like this one?
We will tell you honestly whether we are the right people for it.