Dima Trubnikov

← All work

Caily — HIPAA-compliant communication platform for senior living (live at caily.com)

Caily — Two Years of Design That Could Not Ship

Caily — Two Years of Design That Could Not Ship

Caily — Two Years of Design That Could Not Ship

Two years of design work that couldn't ship. One month to production.

Two years of design work that couldn't ship. One month to production.

Client

Caily — HIPAA-compliant communication platform for senior living (live at caily.com)

My role

Principal Product Designer — end-to-end across web/mobile

Timeline

Stalled 2024–2026 · recovered 2026

Impact

~1,500 inherited design frames → ~300 shipped · 2-year stalled build in production in one month · role-based permission built into the system

The challenge

The challenge

Caily had two years of design behind it and nothing in production. The inherited file held roughly 1,500 design frames across mobile and web. Not 1,500 screens — every state of every screen had been drawn as its own artboard. Empty form, filled form, error state: three hand-made frames where one component with defined states would do. That is why the build had stalled. No frontend team can implement and maintain that surface, and nobody could hold the product in their head well enough to say what "done" meant. Underneath the volume was a second problem: five distinct roles shared one product with no shared system and no permission model in the design. Facility staff at three levels — member, admin, and owner — plus caregivers, family members, and a separate role managing communication across the platform. Each view had been designed independently, so the same record looked and behaved differently depending on where you opened it. The real question wasn't how it should look. It was why design kept producing artifacts engineering couldn't ship.

Caily had two years of design behind it and nothing in production. The inherited file held roughly 1,500 design frames across mobile and web. Not 1,500 screens — every state of every screen had been drawn as its own artboard. Empty form, filled form, error state: three hand-made frames where one component with defined states would do. That is why the build had stalled. No frontend team can implement and maintain that surface, and nobody could hold the product in their head well enough to say what "done" meant. Underneath the volume was a second problem: five distinct roles shared one product with no shared system and no permission model in the design. Facility staff at three levels — member, admin, and owner — plus caregivers, family members, and a separate role managing communication across the platform. Each view had been designed independently, so the same record looked and behaved differently depending on where you opened it. The real question wasn't how it should look. It was why design kept producing artifacts engineering couldn't ship.

Fig. 01 — Who is on either side of it

Product imagery: Caily

Care staff, mid-shift

The people handing off between shifts — on a phone, standing up, between rooms.

Leadership, in the office

The same records in the web app, where staffing and escalation are actually managed.

What I did

What I did

1. Cut the surface by 80%. I mapped the inherited frames against the actual user scenarios and found the same flows redrawn with cosmetic differences. Consolidating them into shared components with defined states took the product from ~1,500 frames to ~300 — same functionality, a fifth of the surface to build, test and maintain.

1. Cut the surface by 80%. I mapped the inherited frames against the actual user scenarios and found the same flows redrawn with cosmetic differences. Consolidating them into shared components with defined states took the product from ~1,500 frames to ~300 — same functionality, a fifth of the surface to build, test and maintain.

Fig. 02 — The same product, three audiences

Shipped — caily.com

Caily — three phones

Announcements a community sends, the feed a member opens, and the resident view a family member sees. The same components, assembled from one system rather than drawn per screen.

Product imagery: Caily

Fig. 03 — The surface, counted

From the working file

3

Products in one file

Mobile, tablet, community web

~1,500

Frames across them

Every state drawn as its own artboard

5

Roles sharing one record

Three staff levels, caregivers, family

80

Design variables

Colour and system tokens, seven collections

That was the problem, not the achievement. Consolidating those frames into shared components with defined states is what took the build from stalled to shipping.

2. Audited against the API, not the mockups. Before redesigning anything I checked every proposed screen against what the backend could actually return. That is where the stall came from: fixing the visual layer without fixing the data model would have produced another two years of unshippable work.

2. Audited against the API, not the mockups. Before redesigning anything I checked every proposed screen against what the backend could actually return. That is where the stall came from: fixing the visual layer without fixing the data model would have produced another two years of unshippable work.

3. Built the permission model into the design system. Three staff levels, caregivers, family, and chat management — one record, different visibility per role. HIPAA makes this a legal requirement, not a preference. Permission became a property of each component rather than a per-screen decision, so a caregiver's view and a family member's view are the same component under different access, not two designs to maintain.

3. Built the permission model into the design system. Three staff levels, caregivers, family, and chat management — one record, different visibility per role. HIPAA makes this a legal requirement, not a preference. Permission became a property of each component rather than a per-screen decision, so a caregiver's view and a family member's view are the same component under different access, not two designs to maintain.

Fig. 04 — One product, five roles, three surfaces

Shipped — caily.com

Caily — devices

One record, different visibility per role — three staff levels, caregivers, family, and chat management. Permission became a property of each component rather than a per-screen decision.

Product imagery: Caily

4. Wrote design contracts with engineering. Component architecture agreed with the frontend team, so a screen is assembled from known pieces rather than interpreted from a mockup. That is what took the project from stalled to shipping in weeks.

4. Wrote design contracts with engineering. Component architecture agreed with the frontend team, so a screen is assembled from known pieces rather than interpreted from a mockup. That is what took the project from stalled to shipping in weeks.

The solution

The solution

The product went to production in about a month and is live at caily.com — after roughly two years without a release. Roles now run on one design system with permission built in. Engineering ships from components instead of re-interpreting mockups screen by screen, and ~300 screens carry what 1,500 frames couldn't.

The product went to production in about a month and is live at caily.com — after roughly two years without a release. Roles now run on one design system with permission built in. Engineering ships from components instead of re-interpreting mockups screen by screen, and ~300 screens carry what 1,500 frames couldn't.

What I’d do differently

What I’d do differently

I ran the API audit first and it saved the project — the existing designs described a data model the backend couldn't return, and no amount of visual work would have fixed that. But I presented it as a design finding, in design language, and it took two weeks to get the team to act on it. Framing it from the start as a delivery risk with a cost attached would have moved faster. The analysis was right; the packaging cost me time.

I ran the API audit first and it saved the project — the existing designs described a data model the backend couldn't return, and no amount of visual work would have fixed that. But I presented it as a design finding, in design language, and it took two weeks to get the team to act on it. Framing it from the start as a delivery risk with a cost attached would have moved faster. The analysis was right; the packaging cost me time.

More work

All case studies →

All case studies →

All case studies →

d.trubnikov@me.com

© 2026 Dima Trubnikov · Vilnius, Lithuania (EU)