Skip to content
SOFTRIZQSoftrizq home
All work
Health & accessibility2026Client confidential

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

  1. 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.

  2. 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.

  3. 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.