Each community arrives at a door built around how they talk about care, not at a translated version of somebody else's.
KeevaathTech/Products/MaatraCare
Product · Live since June 2026
MaatraCare
An elder care platform for diaspora families, built around one decision: a separate entry point per community, in the words that community already uses.
What it does
An elder care platform for diaspora families supporting aging parents in another country. The hard part of remote caregiving is seldom a lack of concern. It is distance, time zones, and the difficulty of arranging trustworthy care in a place you are not.
One architectural decision shapes the whole product. One interface translated many times would have been cheaper. MaatraCare instead runs a separate entry point for each cultural community, each in its own language and using the words that community already uses for care.
What is in it
An entry point per community
Made for distance
Coordination between a family in one country and a parent in another, across time zones, without either side having to be awake at the wrong hour.
Care coordination
Visits, medication, appointments and updates in one place, so everyone supporting a parent is looking at the same picture.
Works on a poor connection
Updates queue when the connection drops and reconcile when it returns, so nothing is lost because somebody was on a train or in a hospital basement.
Emergency alerting
The only failure class that genuinely matters, and the one the whole system is built around.
Provider coordination
Arranging and tracking care from people you cannot meet in person, with a record everyone can see.
The hard problem
This platform approached the same problem from the other side. Instead of waiting for testers, we built a harness that would fire every one of two hundred and ten endpoints in a single pass and produce a grid. The first serious run returned four passes and one hundred and fifty three failures. A later run returned one hundred and seventy seven network errors.
A result like that is not a backlog. It is a message about the measurement.
Roughly a hundred and twenty of those failures shared one signature, and a signature that uniform is never a hundred and twenty independent bugs. The blank status codes meant the browser had refused the request before any backend function woke up, which pointed at gateway configuration and not at application logic. One scripted pass across every route resolved the whole group.
The harness itself was responsible for another portion. It was sending a malformed authorization header on some routes and the wrong verb on others, manufacturing failures against functions that were perfectly healthy. There is something clarifying about discovering that your thermometer has a fever. We stopped fixing the code and fixed the test runner first, and a block of failures closed without a single deployment.
Then came the naming. The function serving updates on an elder record was named for a read operation. Another, numbered as though it fetched something, deleted instead. Anyone debugging by reading names was debugging a fiction. The longest running defect was traced through authentication, then gateway configuration, then the backend function, all correct at every step, before landing on a front end route firing with a stale identifier. Four theories eliminated by reading, without touching a production system families depend on.
What it cost, and what changed
The harness moved from its seventh revision to its forty sixth in a little over two weeks, at better than one working session a day, and an identifiable block of failures across that period belonged to the harness and the gateway, not to any application code. Call it two to three working days spent on failures the system under test did not cause, compressed into seventeen days of calendar.
What changed at the start of every build since is that the instrument gets validated before the subject. A test harness is proved against a known good endpoint before its output is allowed to shape a backlog, and naming conventions, rollback artifacts, compile gates and post deployment verification are fixed at project setup, where they cost nothing, instead of somewhere past the hundredth function, where they cost a full re-audit.
Status
Live since June 2026. Funded, designed and operated by the studio.
Questions we are asked
Why one entry point per community instead of one translated interface?
Because a family should not have to explain their parents to a generic interface. It is a deliberate trade: far more surface area to maintain, in exchange for a product that meets people in the words they already use.
Which communities does it serve?
Coverage spans South Asia, Southeast Asia, East Asia, the Middle East, Africa, Latin America and Eastern Europe. The specific list is maintained on the platform itself, where it stays current.
Can care providers or insurers work with it?
Yes, and pilots are the usual starting point. Distribution partnerships with organizations that already reach diaspora communities are the conversations that move fastest.
Who operates it?
KeevaathTech, meaning the team that built it. An unsent emergency notification is the only defect class that genuinely matters, and it is our phone.
Pilot trials, partnerships, licensing or distribution.
Tell us which and we will come to the first conversation prepared. You will usually hear back within five working days, from the person who would run it.