Quokka / SOS

Mobile Companion App for Seniors

Older adults reject most technology built for them. Building one they'd keep using meant treating accessibility as a property of the person rather than the device, and being deliberate about what never belongs on the phone.

Role: Co-founder and sole developer — mobile architecture and implementation
(also built the companion backend; this case study covers the mobile side).
Tom was to be CEO and I was to be CTO of the planned entity, which we never
incorporated before pausing.
Dates: October 2025 – March 2026 (paused)
Team: Two-person company — co-founded with Tom Smith, formerly a senior
marketing executive at Nissan. Shared premise; Tom led product strategy and the
senior-interaction doctrine, I led engineering. During the origin of this project we met with Jason Westigard, Chief Product & Technical Officer at Trax Technologies, who had been a client of mine on an earlier AI engagement.
Stack: Flutter / Dart 3.8, Isar embedded database, Provider, Anthropic Claude + OpenAI APIs
Companion system: Java 21 / Spring Boot 3.5 multi-module backend, also mine.
Status: Working prototype; project paused

Executive Summary

A relationship-first AI companion for older adults, co-founded with a former Nissan marketing executive. I built the Flutter client and the Spring Boot backend: offline-first, with every write hitting the local database before the network, and accessibility stored as a property of the person rather than the device. The interesting decision was what I deliberately kept off the phone, since a product built on memory over time can't store that memory on a device that gets lost. Working prototype, demoed to stakeholders; paused for funding before the two halves were connected.

Origin

The project began as SOS (Seniors On Support), and it started with something Tom Smith and I found we had in common. We had both watched our parents get lost in technology, and overcharged by it — not defeated by one bad product, but worn down by an entire category built as though they weren't in the room. Both of our parents have since died.

What stayed with us was the other half of it. They hadn't only struggled with technology; they had no sense of what it could have done for them. The gap wasn't capability. Nobody had ever shown them a version of it built with them in mind.

We weren't solving our own problem, then — that window had closed. We built this because we kept seeing the same pattern in other people's parents, and because between us we had the two halves it would take to do something about it.

That framed the problem. Seniors reject most technology built for them, and the AI companion products they don't reject are built for entertainment rather than for the specific realities of aging. Tom brought a career at Nissan spent on how products earn trust; I brought the engineering. The product answer was a relationship-first system — companionship and task assistance deliberately kept separate, trust built progressively rather than assumed at install. My job was to build the client that could carry it.

What I Built

A cross-platform Flutter application — phone first, with desktop builds from the same codebase — that serves as the senior-facing surface and, architecturally, as the bridge between a wearable and the backend.

The shipped prototype provides:

Scale is honest and small: 3 entities, ~3,650 hand-written lines of Dart across 58 files, plus ~2,780 generated. This is a working prototype, demoed to stakeholders and put in front of elderly family members informally. It has not been through a structured pilot, and I don't claim outcomes from it.

What that informal use did produce was one clear, repeated signal: font size and readability mattered more than anything else in the interface. Not the AI, not the features — whether the text could be read comfortably. That is why font scaling is stored per screen and persisted to the user's profile rather than left to a device-level accessibility toggle, and it is the one design decision in this app I can trace directly to a real user rather than to doctrine.

Architecture — The Decision I'd Defend

Every write goes to the local database first, and the network is never in the critical path of the UI updating.

Each entity moves through four layers: a plain Dart model the UI works with, a converter, an Isar @collection DB model, and a static CRUD service. Every record carries created, updated, dirty, and active metadata. Deletes are soft — active = false, never physical removal.

Two things fall out of this that matter more than the pattern itself:

  1. The app works fully offline today. For a product whose users may have unreliable connectivity, an interface that stalls waiting on a network round trip isn't a degraded experience — it's a broken one.
  2. The sync layer is pre-staged. The dirty flag and timestamps are exactly the bookkeeping an outbox-style sync engine needs. When the backend connection is built, it's a service that operates generically over all dirty records across all entities — not a per-entity retrofit. No schema change required.

Adding an entity is consequently mechanical rather than a design decision: model, converter, DB model, service, optional command handler and seed file. Three entities exist; nothing in the pattern limits that number.

The Hard Part

The honest answer isn't the Flutter work or the offline data layer. It's this:

The product is longitudinal, and the client I built is not.

The strategy — Tom's — is built on Longitudinal Human Support Intelligence: observe deeply over time, interpret carefully, surface responsibly. Patterns over isolated events. Personal baselines rather than population comparisons. An eight-week progressive trust-building journey, with engagement delivered as recurring "Daily Sparks."

Every one of those properties requires memory. The chat client I built is single-turn — it sends the current message to the model with no conversation history attached. There is a historyLimit: 10 sitting in the config file, unused. The prompt history is persisted locally and displayable, but it never reaches the model.

That gap is deliberate and it is the interesting part of the engineering story. A longitudinal system's memory cannot live in a phone client:

So the memory belongs in the backend, and the app's job is to be an excellent surface for it: fast, offline-tolerant, accessible, and dumb about interpretation. Building the client without that memory — and structuring it so the memory could arrive later without a rewrite — was the real design work. The dirty-flag architecture above is what makes that arrival cheap.

I built both sides of this system, so the split is a decision rather than a constraint I inherited: I chose to keep the phone client thin and deliberately stateless about interpretation, and to put the longitudinal work in the Spring Boot backend where it could be audited and where two different customers could be served different views of it. The backend is its own case study; what matters here is that the mobile architecture was designed against a known other half.

Designing for Cognitive Accessibility

Tom's interaction doctrine set the constraint I built against, and its foundational line is worth quoting because it drove real technical decisions:

Quokka is not optimized to be impressive. Quokka is optimized to be dependable.

Concretely, that meant: time anchored absolutely ("Tuesday morning at 9") rather than relatively; repetition treated as a safety feature rather than a bug; context recovery that never implies the user made a mistake.

What I implemented against it is smaller than the doctrine and I want to be precise about that. Font scaling is stored per screen and falls back to a global value — a reading-comfort preference that follows the user's profile rather than a device accessibility toggle. The mechanism is general; it is currently wired into the chat screen only. Screen help text is config-driven so Tom could tune the language without a developer or a build.

The per-screen granularity was not over-engineering for its own sake: the readability signal from informal use was strong enough that I wanted the comfort setting to be a property of the person, portable across screens and surviving reinstall, rather than something re-tuned per device. That is the same reasoning that puts it in the profile record instead of in local device settings.

The interaction doctrine is largely unimplemented in the client. Most of it belongs in the layer that has memory.

The Wearable Bridge

The intended shape has the phone or tablet as hub rather than as the senior-facing surface: the backend pushes a message, the phone receives it, and the wearable delivers it by voice. The wearable never talks to the backend directly.

One design property is worth stating because it was a deliberate choice rather than an implementation detail: in the researched design, captured audio goes to a third-party speech-to-text and emotion service, and only the resulting text and sentiment scores are sent to the backend — raw audio is discarded on-device and never transmitted or stored. For a product whose whole proposition is trust, minimizing what leaves the device is a product feature, not just a bandwidth optimization.

The target surface was Meta Ray-Ban smart glasses, paired to the phone over Bluetooth via Meta's Device Access Toolkit. An earlier product brief assumed a smartwatch; we moved to glasses because the interaction we wanted was voice-first and hands-free. A watch still asks a senior to look at a small screen and operate it with the other hand — for our users, that's the interaction model that was already failing them. Glasses let the system speak and listen without asking anyone to learn an interface.

Status: not implemented. No push notification handling, glasses pairing, on-device TTS, or STT client exists in this codebase. The direction was settled and the design researched; the build stopped when the project paused.

Scope Note

The product strategy — the LHSI framework, the eight-week trust journey, Daily Sparks, the dual-customer model, and the senior-interaction doctrine — is Tom Smith's work, developed from a career in how products earn trust with people who have reason to be skeptical of them. I've described what it required of the system rather than reproducing it.

I own the code and the mobile architecture. The relationship model was Tom's; the system to execute it was mine.

Outcome

The project is paused, not abandoned. What exists is a working prototype: demoed to stakeholders, used informally by elderly family members, and backed by a separate multi-module Spring Boot system (access-control, AI-provider, emotion, reporting) that I also built. The app and backend were never connected — that integration is the next piece of work, and the mobile side is structured for it.

At the point we paused, we were in conversations with retirement communities as the distribution channel — the operators, rather than seniors or their adult children, as the way in. No commitments were made and no pilot was scheduled. We paused for funding: two people could build and demonstrate the system, but not run a senior-facing product at the scale those conversations pointed toward.

A nonprofit structure was the intended model, chosen for credibility and trust in a market where both are hard to earn. It was never established.

From my co-founder

I have known Jeb since college and he is without doubt one of the smartest and most insightful people I have ever met. His well-rounded views give him an uncanny ability to come at complex problems from multiple, unexpected angles, and his solutions are most often elegant and lasting. What I really love about working with Jeb are his enthusiasm and humor, which he brings to the job day-in, day-out without fail. He is easy to talk to and work with, and takes constructive criticism with grace. He has saved my bacon more times than I can count and I can always count on him in a pinch. In short, he's everything I could wish for in a business partner, and I can't recommend Jeb enough.

[Tom Smith](https://www.linkedin.com/in/tom-f-smith-552ba33/), co-founder of Quokka; formerly a senior marketing executive at Nissan.