Inspiration
The cycle started with my own laundry problem.
Freshman year on Old Campus, doing laundry was chaos. Finding an open machine felt impossible, so I gave up on weekends entirely and started my loads late on Wednesday or Thursday nights just to get a washer. I told myself sophomore year would be easier. It was worse. Now I was competing with sophomores, juniors, and seniors all at once, and the weekend crunch was not ideal, to say the least.
At some point I stopped treating it as bad luck and started seeing it as a design problem. Laundry at Yale is now free, which is great, but free did not fix the part that actually breaks people: there is no fair way to share a small number of machines when everyone wants them on the same three days. That is the problem Cycle goes after.
What it does
Cycle is a booking layer for the machines Yale already has. You reserve a washer the way you would book a study room, and the app pairs a dryer to it automatically so you are never stranded with a wet load and nowhere to dry it. A few things hold it together:
- A weekly calendar so you claim a time instead of gambling on a full room.
- A washer-to-dryer pairing that belongs to the slot, so the handoff always works.
- A five-minute claim window at the start and a five-minute grace window at the end, so no-shows release automatically and your clothes stay protected while you are on your way.
- A designated cart, so a load that runs late gets moved to a labeled spot instead of onto the floor.
- Reliability points that reward showing up and doing off-peak laundry, which quietly spreads demand off the weekend peak.
- A walk-in pool that can never be booked, so anyone can always show up and wash.
How I built it
The hard constraint was "no new machines," so every mechanism had to make the existing machines more usable rather than adding more. I leaned on Nir Eyal's Hook Model from Hooked to shape the loop: the reminders are the trigger, the two-tap booking is the action, points and weekend priority are the variable reward, and building your reliability is the investment that pulls you back the next week. I designed it around Jonathan Edwards, given that I have the most familiarity with it.
Challenges I ran into
The biggest one was almost invisible: a reservation system makes scarcity worse, not better. If people reserve and do not show, machines sit idle during the exact hours everyone needs them. So the entire design had to be built around reservations that self-release. The second challenge was fairness. Reservations can quietly favor whoever is most online, so I kept a protected walk-in pool and capped weekend hoarding. And quite frankly, I was very much stumbling around Figma and had a lot of complications with it because I'm not too familiar; the last time I used it was 2 years ago.
What I learned
I learned to design for fairness, not just for the people already using the app. The auto-release, the protective lock, and the off-peak reward all do their job by making the good behavior the easy behavior. I also learned to design for the person who does not use the app at all, because a solution that only works for power users is not really a solution.
What's next
The user analysis is still ahead of me, and I built Cycle so it can be measured honestly once it is in real hands. I would instrument it with a tool like Mixpanel or PostHog and watch:
- A funnel from opening the app, to first booking, to actually collecting a load, to see where people drop off.
- Weekly retention, since the whole point is a habit, not a one-time novelty.
- Which states and features get used versus ignored.
- Segments that were a design priority from the start: weekday versus weekend users, planners versus walk-ins, and new versus reliable students.
The goal is simple: prove that the same machines can serve a lot more people if you schedule them fairly.
Built With
- books
- claude
- figma
- youtube
Log in or sign up for Devpost to join the conversation.