Learning and therapy tools
Products children use directly — screening, remediation, vocabulary, practice. Built for a specific cohort, curriculum or language rather than adapted from something generic.
Urdu and EnglishAndroid and webOffline-capable
Services · Custom product development
Software built for how your institution actually runs.
Education institutes, clinics and centres rarely fit the software sold to them. We design and build custom products across the range — from tools children use directly to the management systems running the institution behind them — with the same practice that produced EAST, Rawaan, SparkEd and PMS.
What we build
Four kinds of build, one practice.
Most engagements are one of these, and several turn out to need two. We will tell you which you actually need before quoting for the one you asked about.
Institution management systems
Records, scheduling, staff, assessments, education plans and reporting — held in one system rather than spread across spreadsheets, folders and someone's memory.
Role-based accessAudit trailsReporting
Accessibility work on what you run
An audit and remediation of software you already own. Often the fastest route to a usable system: the product is fine, the interface excludes the children it was bought for.
WCAG auditUsability testingRemediation
Research pilots
A prototype built to answer a question rather than to ship. For institutions and funders who need evidence that an approach works before committing to it at scale.
Study designPrototypeFindings report
Process
We start in the room, not the spec.
The failure mode in this sector is software specified in a meeting and delivered to people who were never asked. Every stage below exists to prevent that.
01
Fieldwork
Time with the staff, children and families who will use it. Observation and interviews before anything is specified.
2–4 WEEKS
02
Design
Flows and interfaces drawn against what we saw, with accessibility decided at this stage rather than retrofitted later.
3–5 WEEKS
03
Prototype
Something testable early, put in front of real users rather than described in a document you have to imagine.
4–6 WEEKS
04
Build and trial
Developed and trialled in the setting it is for. Findings from the trial change the product, not just the report.
VARIES
05
Handover
Your staff trained by the team that built it, with documentation and a support arrangement agreed in advance.
ONGOING
Timelines are indicative. A single-purpose tool can run to twelve weeks end to end; a management system replacing existing records takes longer, mostly because migration and staff training take longer than the software does.
Track record
We build for others the way we built for ourselves.
Our own four products went through exactly the process above. They are the clearest evidence of what this practice produces.
Screening tool
EAST
50+ activities, published at CHI, live on Google Play.
Therapy game
Rawaan
Adaptive difficulty, in-depth reporting, first of its kind in Urdu.
Learning app
SparkEd
Icon, text and voice on every card, in two languages.
Management system
PMS
Scheduling, records, sessions and a patient timeline in one place.
Engagements
Three ways to start.
Not every institution is ready to commission a build, and not every problem needs one. These are the three shapes an engagement usually takes.
Discovery2–4 WEEKS
Fieldwork and a written recommendation. You end with a clear brief and costed options — including, sometimes, the recommendation not to build.
Full build12 WEEKS +
The whole process, from fieldwork through handover and staff training, with a support arrangement afterwards.
Retained teamMONTHLY
Ongoing design and development capacity for institutions running several systems, or improving one over years rather than months.