I designed a service where hosts and cleaners don't argue over whether the cleaning was done.
RumiClean, a cleaning-matching service connecting Airbnb hosts and cleaners (client project)
- Period
- Nov 2025 – completed
- Role
- PM · Frontend · Design (team of 3)
- Status
- Client project · Completed
Summary
A client project: an Airbnb cleaning matching service. Hosts and cleaners who've never met need the completion standard to live inside the service, so I fixed the five-state job flow first and made five before-and-after photos the condition for completion. I built the entire cleaner-side app myself, shipped it, and wrapped up the engagement.
Impact
- completion proof · before/after photos
- 5 photos
- job flow the cleaner screens were derived from
- 5 states
- planning through deployment · wrapped before payments
- Delivered
Background
- Airbnb hosts struggle to find reliable cleaners; cleaners struggle to get steady work. We set out to build a matching service — and to actually operate it with real users, not finish it like a hackathon project. (Client project · Nov 2025 through completion, 3-person team — service name RumiClean)
- As overall PM I own planning, design, and release priorities, and built the entire cleaner-side frontend myself.
Execution
PM — Priorities & Deployment Decisions
- Set priorities from feature work to deployment; manage code review, release merges, and QA across a 170+ PR repository.
- Simplified deployment from k3s/ArgoCD to Docker Compose + Caddy to match a 3-person team, and served static files from a CDN (CloudFront) so pages stay up during deploys.
Process-Driven Screen Design
- Defined the cleaning job lifecycle as a state machine (pending → scheduled → in progress → review → settlement) and derived each screen and its inputs from the states.
- Completion requires at least 5 before/after photos — a policy that makes the service the custodian of evidence in host-cleaner disputes.
- Implemented production integrations (Kakao Map search, Firebase Web Push) and keep team code consistent with atomic design and data-testid QA conventions.
Pending
Request list — check place, date, options, pay; accept or decline
Scheduled
Job detail + calendar — entry method and place info
In progress
Progress shown — no extra input asked while working
Review
Completion proven with 5+ before/after photos and notes
Settlement
Settlement status shown — cleaners see when they'll be paid
I fixed the state flow before the feature list and kept only the screens and inputs each state needed. Dev and QA scope were split along the same flow.
Results
- Deployed to www.rumiclean.com with GitHub Actions auto-deployment, then wrapped up the engagement before Toss payments were connected, so it never took real users — my first client project carried through the full cycle: planning, design, development, deployment, and QA.
What I learned
- Ops complexity has to match team size. Keeping k3s running was eating into a three-person team's feature time, so I simplified to Docker Compose and Caddy, and swapping tools stabilized the service more than adding features would have.
- Write the feature list first and you only multiply screens. Fixing the state flow first distilled the screens and inputs we actually needed — and scope negotiations happened on top of that flow.