conflict
mobile
workspace

ShiftFair — Fairer Shifts. Clearer Decisions.

Inspiration

Volunteer scheduling seems straightforward until real-world constraints enter the picture. Some people are unavailable, some assignments cannot be changed, certain shifts must be covered, and distributing work equally is not always possible.

The problem isn't simply filling a calendar. It's finding a workable schedule without quietly placing a disproportionate burden on a few volunteers.

I built ShiftFair to explore a practical question: Can we make volunteer scheduling fairer while keeping essential coverage and existing commitments intact?

What it does

ShiftFair is a browser-based, constraint-aware volunteer shift planning application designed to make scheduling decisions more transparent.

It focuses on four priorities:

Required coverage: Keep mandatory shift requirements satisfied.
Protected assignments: Preserve locked commitments instead of silently overwriting them.
Workload fairness: Evaluate how scheduling decisions distribute individual burden.
Transparent outcomes: Make coverage, constraints, and workload trade-offs easier to understand.

Rather than treating fairness as a vague promise, ShiftFair makes it something that can be examined through concrete scheduling scenarios.

How I built it

Development started with a structured Skill Pack defining the scheduling problem, expected behavior, hard constraints, and verification requirements.

The initial scope used a planning scenario involving 12 volunteers and eight shifts. The implementation was developed and checked through an iterative workflow, with particular attention to preserving constraints and distinguishing actual evidence from assumptions.

The application uses a browser-based interface, JavaScript/Node.js tooling, and Firebase Hosting for its public deployment.

The implementation and release workflow included automated Node.js tests, local browser verification, public deployment checks, and artifact integrity verification.

Challenges I faced

1. Fairness versus coverage

Reducing one volunteer's workload means little if mandatory coverage disappears. ShiftFair needed to account for fairness without overlooking required assignments.

2. Respecting locked commitments

A scheduling change must not silently invalidate assignments that were explicitly protected.

3. Making results understandable

A useful scheduling tool should communicate workload distribution and constraints rather than merely displaying a completed roster.

4. Verifying the deployed application

Passing local tests does not automatically prove that the public application is serving the same tested build. I therefore included public browser checks and release artifact verification.

Accomplishments

ShiftFair has reached a publicly deployed and technically verified release.

The completed verification includes:

27 passing Node.js tests
15 passing local browser checks
15 passing public browser checks
10 public application files verified against the tested release artifact

In a controlled synthetic fixture, the maximum individual burden decreased from 8 to 2, while all four required slots remained covered.

This result demonstrates the behavior of the implemented scheduling logic in that specific test scenario. It is not a claim of independently measured real-world impact or a completed volunteer user study.

What I learned

The most important lesson was that generating a schedule and producing a trustworthy schedule are different engineering problems.

Hard constraints need explicit protection. Fairness needs visible measurements. And a successful test result needs enough supporting evidence to distinguish actual behavior from an attractive demonstration.

I also learned the value of keeping planning decisions, automated tests, and deployment verification connected throughout an AI-assisted development workflow.

What's next

The next milestone is genuine hands-on review with the project owner and prospective users, followed by improvements based on observed usability problems and practical scheduling needs.

Future work can explore broader scheduling scenarios, more nuanced workload preferences, and clearer explanations of unavoidable scheduling trade-offs.

The immediate priority is validating whether the existing technically verified application is genuinely useful to people managing volunteer schedules.