I recently built a small tool called Shift Schedule Maker.

At first, I thought shift scheduling would be a fairly straightforward problem.

You have employees.
You have shifts.
You assign people to shifts.

That sounds like a simple table.

But once I started building it, I realized scheduling is less like filling out a calendar and more like solving a constraint problem.

A valid schedule is not necessarily a good schedule.

For example, the system has to think about things like:

• Does every shift have enough people?
• Is anyone assigned to two overlapping shifts?
• Is someone working too many days in a row?
• Are night shifts distributed fairly?
• Are weekends always falling on the same person?
• What happens when one person is unavailable?
• Can the schedule still work if the team size is small?

The tricky part is that these rules often conflict with each other.

You might want perfect fairness, but still need full coverage.
You might want to respect everyone’s availability, but only have a limited number of people.
You might want a simple repeating pattern, but real-life exceptions break the pattern very quickly.

That made me think about scheduling differently.

Instead of treating it as a calendar UI problem, I started treating it as a constraint-solving problem.

Each shift becomes a slot that needs to be filled.
Each employee has limits, availability, and workload history.
Each rule adds pressure to the system.

Some rules are hard constraints:

• A person cannot work two shifts at the same time.
• A shift cannot be left uncovered.
• An unavailable employee should not be assigned.

Other rules are softer:

• Try to balance total working hours.
• Try to distribute unpopular shifts.
• Try to avoid too many consecutive workdays.
• Try to keep the result understandable for a human manager.

That last part is easy to underestimate.

A schedule can be mathematically valid and still feel wrong.

For example, if one person gets all the night shifts, the algorithm might still satisfy coverage. But from a team perspective, the result is bad. So the goal is not just “generate something that works.” The goal is to generate something that feels reasonable.

Another challenge was templates.

Many industries already use known rotation patterns, like 12-hour shifts, 4-on/2-off, Pitman-style schedules, or 2-2-3 rotations. These patterns are useful because they give structure. But once you add employee availability or custom rules, the template becomes only the starting point.

So the product became a mix of two ideas:

1. Start with common scheduling patterns.
2. Adjust the actual result based on constraints and fairness rules.

I’m still improving the logic, especially around edge cases where the input is technically possible but very tight.

For example, if there are too few employees for too many required shifts, the system should not simply fail. It should explain what is making the schedule difficult.

That is probably the most interesting part of the project so far: not just generating the schedule, but helping people understand why a schedule is hard to generate.

I made the tool public here:

https://shiftschedulemaker.net/

It is still evolving, but building it has made me appreciate how much hidden complexity exists behind something as ordinary as a weekly shift calendar.

Curious if anyone here has worked on scheduling, constraint solving, workforce planning, or optimization problems.

How would you approach fairness in a scheduling system?