giving my mom her evenings back
/ tl;dr
My mom is a head nurse. For years she built her team's monthly shift schedule by hand: about 20 hours every month, in the evenings, after work.
Runos is the product we built to take that off her table. It turns a pile of constraints into an optimized schedule in under a minute. I designed it from scratch, and once AI tools made it possible, I built the entire frontend myself.
She's been running her real schedules on it for six months now. The 20 hours are down to about 5 minutes.
/ the problem
Hospital schedules, planned by hand, on personal time.
A hospital team runs on a strict roster: who works days, who works nights, who rests, who covers. My mom did it by hand. At the end of every month, our kitchen table disappeared under printed tables while she fitted the pieces together.
A schedule only counts as done when every constraint is met, and everyone is happy with it. That took her around 20 hours, every month, unpaid, in the evenings.

/ the design
Same grid, nothing to relearn.
I kept the mental model simple, because my first user was never going to sit through onboarding.
Most of the design work went into the generate-schedule flow. Every constraint had to become something a head nurse could express in plain language, not math: min and max shifts, rest days, preferences, time off.
The schedule itself stayed a grid on purpose. Same rows of names, same shift codes as the paper she already made. The only difference is that this grid fills itself.
I didn't build it alone. A developer partner took the hard part: the backend, and the algorithm that actually solves the constraints. My side was everything a user touches.

/ the turn
No more handoffs.
Over the last six months, AI tools got good enough that I could stop handing designs off. With Claude Code and Cursor, I now build the entire frontend of Runos myself: every screen, every flow, every adjustment.
/ working on the table itself.
The schedule grid is the product. You drag across a row of days, pick a shift, and the cells fill. Hover, press, drag, the menu that appears: that's a lot of states. Designing each one in Figma, then waiting for someone to build it, still wouldn't tell me if dragging a week of vacation felt right.
Once I could build it myself, I stopped mocking the table and worked on it in the app. I could feel whether the drag landed, whether the menu got in the way, whether marking a shift felt as direct as a pen on paper.
/ two sidebars became tabs.
I had started with a layout every SaaS uses: a main sidebar, then a second one for the team. Overview, members, schedules, settings. It looked familiar. It also ate the one thing this product actually needs: width.
A month is a row of days, plus names, plus totals. The second sidebar was space the grid couldn't use, so I replaced it with tabs. Navigation got simpler, and the schedule finally had room to be a schedule.


What changed isn't only speed. Nothing gets lost in translation anymore. The person who decides how it should feel is the one who makes it so.
/ the product today
A month of constraints, solved in under a minute.
/ first step: set up the team.
This is currently the slowest step. Moving from paper to the product means adding every name and team by hand, and we're looking at ways to make that easier.
/ second step: set the rules.
Legal constraints and personal ones, in plain language: how many people on days and nights, rest days, preferences, time off. These are the same pieces she used to juggle on paper.
/ third step: generate.
The algorithm takes the constraints and returns an optimized month in under a minute. You can edit the schedule afterwards, then export it and send it by email.
/ the outcome
20 hours became 5 minutes.
Runos has no growth chart to show. What it has is one head nurse who has run her team's real schedules on it for six months. What used to take around twenty hours a month now takes about five.
That's the outcome I care about: her evenings are hers again. She's also still my sharpest critic and every use comes back as feedback, and the product keeps moving because of it.






