Woojik
Shift Work Matching Platform
Match shifts by actual availability—not application volume.
- Design · Engineering
- 2026
- Web · Marketplace
- Solo — Design & Engineering
- Part-time workers, local businesses in Seoul
- Marketplace · Maps · Matching
I designed and built both sides of the marketplace, the matching model, and booking states.
Visit live site
Overview
Woojik turns two calendars into one match: when a worker can work and when a business needs help.
Shift work still gets matched one phone call at a time.
- 88
- 2
- E2E
Problem
Availability Was Trapped in Phone Calls
Job posts describe the role. They rarely answer the first question that decides a shift: can both sides make the same hours?
- Availability checked one call at a time
- Workers could not search by their open hours
- Businesses could not see overlap before outreach
Core decision
Match the Calendar, Not the Résumé
Workers mark availability. Businesses publish demand slots. Woojik scores the overlap before either side starts a conversation.
- Time overlap is the primary ranking signal
- Role and location refine the match
- Urgency, pay, and hours stay visible on every card
Product system
Two Roles. One Schedule Model.
Worker and business flows stay separate in the interface and meet in one shared matching and booking model.
- Worker: availability, discovery, acceptance
- Business: demand, candidates, booking
- Shared: match score, status, expiration
Current state
Both Sides Are Complete
Matching, map discovery, acceptance, and the booking lifecycle are implemented across both roles.
- 88
- 2
- 5
- Live
Reflection
Key Learnings
Time Is the Matching Unit
Role and distance matter after the schedules overlap.
One Data Model, Two Products
Shared states kept both sides honest without forcing the same interface.
Maps Need Boundaries
A visible search area improved relevance and performance together.