A post here convinced us that "fair rotation" is a tracking problem, not a scheduling problem

I build scheduling software (ClockOut), so read this with that bias in mind. A few weeks ago someone posted here about hand-building monthly schedules for a 15-person healthcare group rotating through hospital positions. The hard requirement wasn't generating the schedule. It was keeping a running tally of how many times each person had done each rotation, and keeping that count close to equal month after month, while still honoring individual requests.

That reframed something for us. Most scheduling tools (ours included, until recently) treat each schedule as a standalone puzzle: fill the slots, respect availability, done. But fairness isn't a property of one schedule. It's a property of the history. You can publish a perfectly reasonable week where Maria gets the bad station again for the fourth time this month, and the tool sees nothing wrong because it doesn't remember the first three.

Once you see it that way, a few things follow:

- The tally has to be visible. If people can see the counts, "why am I always on register" conversations turn from grievance into arithmetic. Half the resentment around scheduling is really uncertainty about whether it's fair, not actual unfairness.

- Requests need to be first-class, not texts. A "prefer" or "avoid" request that lives in a group chat is invisible to whoever builds next month's schedule. If it's recorded against the schedule, honoring it and rebalancing afterward becomes mechanical.

- Qualification limits fairness. In any skilled team, the rotation can only be equalized among people actually qualified for the position, which means the qualification data has to live in the same system as the schedule or the "fair" assignment is wrong.

We ended up building this (positions on shifts, a trailing rotation tally, request workflow, and the auto-scheduler biased toward whoever has the lowest count). Not linking anything since that's not the point of the post.

The question I'd genuinely like this sub's take on: for those of you running rotations by hand, what's your fairness window? Do you try to equalize within the month, the quarter, or "eventually"? And do your people actually care about equal counts, or more about specific stations they hate?

reddit.com
u/Advanced-Strain-3491 — 7 days ago
▲ 2 r/TimeTrackingSoftware+1 crossposts

I built ClockOut for small teams that still rebuild payroll from paper timesheets

Disclosure: I’m the founder. ClockOut is a time clock, employee scheduler, and payroll-export workflow for small hourly teams.

The obvious feature was clocking in and out. The harder part was everything that goes wrong during a real week: someone forgets to clock out, moves to a second job mid-shift, requests a correction, works offline, swaps a shift, or changes a period after payroll has already started. I’ve tried to make those exception paths the center of the product.

What it currently includes:

- phone/PWA punches and a shared PIN kiosk

- GPS stamps and optional geofences

- job codes that can change during an active shift, plus hours-by-job reporting

- employee correction requests, manager review, and edit history

- recurring schedules, availability, open shifts, and swaps

- pay-period locking and CSV files formatted for ADP, Gusto, and QuickBooks

It is not a payroll processor or full construction-accounting system; it tracks the time, review, scheduling, and export handoff. The free plan supports up to two employees; paid plans start at $3 per employee per month.

https://useclockout.com

If you manage an hourly team, which exception still creates the most cleanup for you: missed punches, scheduling changes, job costing, or payroll export?

u/Advanced-Strain-3491 — 7 days ago

Built a shortcut for the app store screenshot part nobody warns you about

Small lesson from building Storeboard: the last 10% of shipping an app is weirdly full of image dimensions, device sets, listing copy, and 1024×500 rectangles.

I turned that pain into a tool. Drop in your URL, screenshot, or description, and it generates the App Store and Google Play image sets at the right sizes. It also handles listing copy and previews.

https://storeboard.dev

I'm still tuning the first-run experience. Does the homepage explain the payoff quickly, or is it trying to say too much?

reddit.com
u/Advanced-Strain-3491 — 29 days ago
▲ 1 r/AppStoreOptimization+2 crossposts

I built the tool I wanted at 1am: app store screenshots from a URL

App store screenshots are such a weird final boss. You finish the app, then spend a day nudging phones around Figma and learning that Google wants 1024×500 for reasons known only to Google.

So I built Storeboard. Give it a URL, screenshot, or description and it makes exact-size App Store and Play sets, plus the listing copy. I also added a full-size preview because downloading every image just to squint at it felt silly.

It's here: https://storeboard.dev

Would genuinely love the brutal version: useful, or did I build an elaborate machine to avoid Figma?

reddit.com
u/Advanced-Strain-3491 — 29 days ago