The Caregiver OS
Designing how 200+ caregivers get paid, rated, and trusted MainStory · 2025
An 18-month redesign of MainStory's compensation system — built as four interlocking products that ship to the same person: the caregiver who needs to trust how she gets paid.
The Setup
MainStory's promise is care. We make it to parents every day. But the people delivering that promise — 200+ caregivers spread across 10 daycare centers — were getting paid through a system that didn't reflect any of it.
A flat salary. Opaque payslips. Overtime that arrived a month late, sometimes never. No way to be recognized for being good at this work versus being adequate at it.
Every payroll day, the same conversation:
"Gajiku 2.8 juta. Kemarin aku absen dua hari, terus pernah pegang rasio 1:3. Beneran kepotong 200 ribu langsung?" "Aku 2.6 juta. Tapi aku gak ngerti breakdown-nya." "Bisa gak payslip-nya lebih detail, biar bisa kita verifikasi?"
Center Managers fielded these questions every single month. They had no data to answer with. Caregivers walked away unconvinced. Trust eroded one cycle at a time.
TODO — the catalyst: what specifically triggered you to start this redesign? A turnover spike? A leadership decision? A particular caregiver whose complaint stuck with you? One vivid sentence here makes the whole case study land.
I treated this not as a payroll fix but as a system to redesign. Compensation is the operating system caregivers experience daily. If it's broken, no amount of friendly app polish at the parent layer can compensate for what they feel.
So I designed four interlocking products. Each shipped separately. Each made the next one possible.
THE FOUNDATION → Payroll Logic
The spec everything else builds on.
Four caregiver types, all reconciled.
THE VARIABLE → Rating + Tipping
Turn quality signal into income.
Differentiate good from adequate.
THE RECONCILE → Overtime System
Close the trust gap between
parent payment and caregiver payout.
THE WINDOW → Payslip Transparency
Make every rupiah explainable
in a screen the caregiver owns.
The Foundation — Payroll Logic
Before any product, the spec.
MainStory has four caregiver types — Sus Koor (center coordinator), Sus Asuh Daycare, Sus Homecare, and Bidan Homecare — each with different base salaries, different attendance bonuses, different performance metrics. Sus Koor cares about child attendance consistency in their center. Sus Asuh cares about Child Attendance Days handled, with a progressive fee structure where the per-CAD value depends on the final total CAD for the month and applies retroactively to all of them. Homecare cares about per-CAD value plus retention bonuses tied to whether the same parent-child-caregiver triplet renews.
Before this work, all of that lived in a Google Sheet, partially in someone's head, and partially in a Retool admin tool that didn't know the rules.
I wrote the canonical spec from scratch. Every variable named. Every edge case explicit. Every rule traceable to a real behavior we wanted to reward or discourage.
The core principle, which became the through-line for everything after:
If it affects salary, it must be visible and traceable.
This is the spec that the engineering team built against. It's the spec that Finance reconciled against. It's the spec the caregivers' app eventually surfaced. One source of truth. No more "cek dulu di sheets."
The Variable — Rating + Tipping
A flat salary tells every caregiver the same thing: what you do here doesn't matter individually.
That message is wrong. It's also expensive — when there's no signal differentiating excellent caregivers from adequate ones, the excellent ones either leave or quietly stop trying.
So I designed a variable income layer with two components:
Rating — quality signal. Parents rate the assigned caregiver, the center coordinator, and the center itself, daily, in 1–5 stars. Rating data flows into KPI baselines for variable bonuses.
Tipping — direct reward. Parents can attach a monetary tip when they rate. Six configurable tiers (Rp 10K to Rp 100K), routed through a dedicated Xenplatform, surfaced in payroll, paid out in full to the caregiver — zero revenue share to MainStory.
The shape of the interaction matters. The tip prompt appears inside the rating flow, not as a separate ask. If a parent gives 5 stars, the rating screen offers tipping in the same gesture. The tipping is optional, gently encouraged, and the button copy changes from "Kirim" to "Kirim dengan Tip" the moment a tier is selected.
What worked
Tipping target: 10–20% of nannies receiving tips monthly. Actual at 6 months: 35.5%. (Nearly double target, sustained.)
TODO — the "why": what's your hypothesis for why tipping over-performed? Was it the gesture design? Cultural fit? Parents had been wanting a way to say thank you and the product gave them permission? One paragraph here turns this from a stat into insight.
TODO — the rupiah: what's the average tip income per nanny per month now? What's that as a % of base salary? This number anchors the whole "variable income that actually matters" claim.
What didn't
Rating missed badly. Target was 50% of parents giving at least one rating per week. Actual: 28% at D+7, declining to ~24% at 6 months.
Same release. Same product. Same parents. Why did one half soar while the other half stalled?
TODO — your hypothesis: what's your read on the Rating gap? Is it that rating-without-payment is just less motivating? That the prompt placement isn't right? That without categories, parents felt rating without context? Don't tell me everything went perfectly — Principal-level reflection means owning the misses out loud. This is the moment that elevates the case study.
The honest read I'd write into the case study, pending your input:
"Tipping worked because it gave parents a concrete way to express something they already felt. Rating didn't, because we'd asked them to do something they didn't have a strong instinct to do — quantify daily care into a 1–5 scale, with no categories, with no clear consequence. We got the gesture right and the abstraction wrong. The fix in V2 is rating categories — not because the math will be more accurate, but because parents need scaffolding to know what to rate on."
If that read is right, we keep it. If it's wrong, you tell me what's actually true and I'll rewrite.
The Reconcile — Overtime System
Before this redesign, overtime was the most fragile part of the entire compensation system. Three things were broken at once:
- Overtime input was wrong. Nanny coordinators logged it manually in the app. The numbers were rarely accurate.
- Caregivers were getting paid before parents did. MainStory was effectively floating overtime cash, paying caregivers monthly while invoicing parents on a different cycle. We were absorbing risk we shouldn't have been.
- Overtime was being split arbitrarily. Different splits in different cases, no rule, no transparency.
I rebuilt the whole flow around one rule:
Overtime is detected automatically. It enters as outstanding payment. The caregiver gets paid 100% — but only after the parent does.
The mechanics:
- The system detects overtime from caregiver clock-in/clock-out against the child's scheduled checkout.
- Overtime is logged on the parent's invoice automatically. If they renew, it merges into the renewal invoice. If they churn, it generates a standalone overtime invoice.
- On the parent app, overtime gets its own UI: a clear flag in the activity timeline, an explainer modal, a sticky bottom-sheet on the renewal screen so it can't be missed.
- On payroll, overtime splits 60/40 — 60% to the assigned Sus Asuh (who actually did the work), 40% to the Sus Koor (who managed the center context that made the work possible).
TODO — the 60/40 logic: how did you arrive at this split? Was there pushback? Did Sus Koor feel under-valued at 40%, or Sus Asuh feel under-valued at 60% (since they did the work)? The reasoning behind the ratio is the Principal-level decision — not the ratio itself.
What worked
Target: ~80% of overtime fully paid by parents before payout to caregivers. Actual at 3 months: 88%. (8 points above target.)
The structural change held. The trust gap between when parents paid and when caregivers were paid out closed almost entirely. Eight percent of cases still slip — that's the remaining design space.
The Window — Payslip Transparency
This was the last piece, and the one that made everything before it feel real to the caregiver.
The Payroll Logic spec, the Tipping flows, the Overtime reconciliation — without a window into all of it, none of it was visible to the person whose paycheck it became. Caregivers were being paid by an opaque system that was fair, but didn't feel fair.
So I designed the payslip the way Talenta, Grab, and BTaskee do it — as a self-service screen inside the Nanny App. Every component visible. Every deduction explained. Every adjustment traceable to a date and a reason.
The components surfaced:
- Base salary
- Attendance — present, absent, late
- Child ratio handling — when a caregiver took on 1:1, 1:2, 1:3
- Overtime — date by date, with payment status (paid by parent vs pending)
- Penalties / deductions — with reason
- Bonuses / adjustments — with reason
- Final take-home pay
Plus a performance dashboard: daily attendance log, child attendance tracker, monthly summary, OT history, ratio assignment history.
The design move I'm proudest of: the screen reads the spec. Not a summary of it, not a translation of it — the same logic the payroll backend computes against is what surfaces, with the same names, the same units, the same math. Nothing is hidden. Nothing needs interpretation. The caregiver can audit her own payslip the way Ops audits a center.
This is the pattern I now apply across every system that affects someone's livelihood: the math is always visible, always traceable, always explainable in one screen. It's the same pattern that made QC Audit's scoring breakdown work. Trust is built in transparent breakdowns.
Released: 28 Jan 2026. Target: ↓ 30–50% salary dispute rate per pay cycle. Status: Too early to confirm post-release metrics; first full payroll cycle measurement pending.
TODO — pre-launch baseline: roughly how many salary disputes per pay cycle were happening before payslip transparency shipped? Even a rough number ("about 20% of caregivers raised at least one question every cycle") makes the eventual delta legible.
One Caregiver Story
TODO: one specific moment. Either a "kenapa gajiku segini?" complaint that haunted you and pushed this work forward, or a reaction post-launch — a CM saying something changed, a caregiver who finally understood her own paycheck. Even an anonymized paraphrase works. This is the human anchor the whole case study needs.
Outcomes
| Subsystem | Metric | Target | Actual |
|---|---|---|---|
| Tipping | % nannies receiving tips monthly | 10–20% | 35.5% (6M) |
| Rating | % parents rating ≥1×/week | 50% | 24–28% |
| Overtime | % overtime pre-paid by parents | ~80% | 88% (3M) |
| Payslip Transparency | ↓ salary disputes per cycle | 30–50% | measurement pending |
Three subsystems shipped to target or beyond. One missed. The miss is the lesson.
The Pattern
I came into this thinking I was redesigning compensation. I ended up redesigning trust — between caregivers and the company, between parents and the people caring for their children, between operations and the data that runs the business.
The trust was always there in MainStory's intent. It just wasn't legible in the system. So my job was to make the system show its work.
Four products, one operating system. None of them is the most beautiful screen in the app. All of them are the reason a caregiver opens the app on payroll day with confidence instead of dread.
"I design operating systems, not interfaces." — and this is the clearest example of why that distinction matters. Not one of these four products is a screen-level feature. Together, they're how MainStory pays its people fairly.
What I'd Do Differently
TODO — your honest reflection: with hindsight, what would you change? Sequence the work differently? Ship payslip transparency first as a forcing function for the others? Validate Rating prompt placement before building Tipping on top of it? One or two genuine "I'd do this differently" moments lands harder than any victory lap.
MainStory · Indonesia's premium childcare platform · 200+ caregivers · 10+ centers