Donghyun Kang.

AI Product Engineer

Caredoc Senior Healthcare Platform | Donghyun Kang | Donghyun Kang

★ Case 05 / 5Product Engineer Donghyun Kang

Caredoc Senior Healthcare Platform

Eight months of moving one domain fact — that a guardian, a facility, and a caregiver stand behind one senior — into the backend model.

스타트업Backend2022.07 ~ 2023.03

App Store Google Play

01.Discover

Behind one senior, there were three other people.

It was a senior-care service, so I assumed I only had to design the senior-user experience well. The backend was sketched on top of that — one user signs up, logs in, receives the service, sees the notifications. One single-user model looked like it would be enough.

The reality of building the service was different. The person paying and the person matching a caregiver were both the guardian; the person receiving the service was the senior; the person performing the care was the caregiver at the facility. Paying, matching, receiving, and performing were spread across four different people, and the single-user assumption did not fit anywhere.

Field notes

Note 01

One senior, three people

Guardian, facility, and the senior themselves all read the same data at once — this was not a "one person, one screen" model.

Note 02

Permissions attach to the role, not the user

Billing rights, view rights, and admin rights were distributed differently across the three seats.

Note 03

Paying, matching, and receiving were three different people

The guardian both paid and matched the caregiver; the person receiving the service was the senior.

02.Build with AI

Moved the domain fact into the model.

Decision 01

Permissions — attach to roles, not users

Attaching permissions to the user could not hold the fact that guardian, facility, and senior each have different rights. Attached permissions to the *role* instead, and redrew the model so a single senior's data can be reached from three seats with three different views. The Node.js → Spring Boot 3.x rebuild was the exact moment to absorb that redefinition.

BeforeSingle-user permissions — N rights tied to one user

AfterA role-based permission matrix — three stakeholders × N rights

tradeoffImplementation complexity vs. domain accuracy

Decision 02

Billing and matching — two rights on one guardian; the recipient is someone else

The real flow: the guardian paid, the guardian matched the caregiver, and the senior was the one receiving the service. The domain did not work if one user did all three. Bundled billing and matching rights onto the guardian role and separated the recipient (the senior) from the billing and matching screens — composed entirely different data views for each.

BeforeBilling, matching, and receiving assumed to be the same user

AfterBilling and matching rights live with the guardian; the senior is the recipient

tradeoffA simple user model vs. the domain fact as it actually is

03.Prove with metrics

It got absorbed into ops.

Spring Boot 3.x migration

8 months

Node.js → Java/Spring — the seat where permissions, billing, and matching were redefined

3 months post-launch

10k downloads

Team result

User satisfaction

4.5 / 5.0

Team result — absorbed the permission, billing, and matching incidents that hit in ops

What this case is really about

“Eight months of moving domain facts into the backend model — making room inside it for the three people standing behind a single senior.”

Discover

Surfaced the domain fact that behind a single senior, the guardian, the facility, and the caregiver each read the same data differently.

Define

Redefined the domain model on top of the single-user table: permissions belong to roles, not to users.

Build

During the Node.js → Spring Boot 3.x rebuild, redesigned the permissions matrix and split billing from matching in the same eight-month push.

Prove

10k downloads and 4.5 satisfaction within three months post-launch (team result) — the new model absorbed the permission, billing, and matching incidents that came up in ops.

Linked principlesDomain-DrivenPragmatism

App Showcase