Omassist

Omassist is a health-tech startup building an AI-driven platform for the home care industry, serving the agencies and registries that coordinate caregivers for elderly, disabled, and recovering clients across the United States. The product is not one application but an ecosystem: a desktop SaaS hub where agencies run matching, scheduling, billing, and compliance, and a dual-sided mobile app where the people at the other end of that operation actually meet. The Client App is for individuals and families requesting care. The Caregiver App is for the professionals delivering it.

The U.S. home care market is worth over $100 billion and is growing on the back of an aging population and a clear preference for care at home over institutional settings. Almost none of it runs on modern software. Agencies still coordinate through spreadsheets, phone calls, and paper compliance forms, which means the industry has scale and regulatory pressure without the tooling to handle either.

The failures in home care are structural, and they look different depending on where in the chain you sit.

Agencies match clients to caregivers by hand. Staff work through profiles looking for someone available, which in practice makes availability the only criterion that reliably gets used. Skill specialization, language, personality fit, and travel distance get considered when there is time, and there usually is not. Poor matches produce turnover on one side and dissatisfaction on the other. Meanwhile scheduling, billing, compliance, payroll, and communication each live in a different tool, so office staff spend most of their time on administration rather than care oversight, and nobody has real-time visibility into utilization, revenue, or compliance status. Decisions get made reactively because the data to make them any other way has to be assembled by hand.

The organising decision was to treat the visit as the unit the whole ecosystem is built around. Every surface, agency dashboard, client app, and caregiver app, is a different view onto the same lifecycle: a request is made, a caregiver is matched, the visit happens, it is verified, and it is paid for. Designing that lifecycle first and giving each participant their own entry point into it is what kept three interfaces behaving as one product rather than three applications sharing a logo.

The **agency SaaS platform** is the operational hub. AI-powered matching analyzes certifications, experience, language proficiency, personality traits, location, and real-time availability to recommend caregiver and client pairings, replacing hours of manual coordination with recommendations that surface in seconds, with real-time conflict detection preventing double-bookings. Automated billing runs the full lifecycle from timesheet capture and verification through invoice generation, claim submission, and payment tracking, with multi-payer rate tables and automatic documentation attachment. A centralized dashboard gives agency leaders a single view of the operation with monthly recurring revenue, total and paid member counts, email engagement, trend indicators, time-range filters, exportable reports, and content management tools.

Designing for four audiences taught me that the shared object matters more than the shared interface. My first instinct on a product this broad is to look for what can be unified at the surface, and here the answer was almost nothing: the agency dashboard, the client app, and the caregiver app have different densities, different rhythms, and different jobs. What they do share is the visit. Once I designed the visit lifecycle as the fixed structure and treated each product as a view onto it, the question of how much interface to share stopped being an efficiency argument and became a straightforward one about who needs to see what. I now look for the shared object before considering the shared system.

Compliance features are interaction design problems, not documentation problems. I approached Electronic Visit Verification initially as a matter of capturing the right fields, since the regulatory requirements are explicit about what has to be recorded. The actual difficulty was where and when it gets captured, at the end of a shift, on a phone, in a client's home, with a second signature needed from someone who may be elderly or unwell. Getting the fields right is necessary and does nothing on its own. Designing for the moment of capture is what makes the record accurate, and I would start there on any regulated workflow now.