05

Vardiya — a scheduler that encodes the rules instead of approximating them

In development2026 —Constraint solving · TypeScript · PostgreSQL · Operations tooling

Designed and specified, not yet built. The problem and the decisions below are real; there are no screenshots or results, because there are none to show.

The problem

The defining property of custom internal software is that it encodes an operation's actual rules — its rate structures, crew logic, approval chains, its compliance requirements — instead of approximating them through a settings screen. Configurable is not correct, and the last tenth of a business's rules is the part no configuration screen can express and where the entire cost sits.

So the process stays in a spreadsheet, and the state of those is well documented: hours lost every week to reconciling discrepancies, errors in most operational sheets, and no permissions and no audit trail on a document that decides people's working hours.

Replacing it is not a matter of drawing a nicer calendar. It is that a roster has to satisfy rules that are genuinely combinatorial, and a tool which cannot say why no valid roster exists sends the planner straight back to the spreadsheet.

Decisions

  1. Where do the business's rules live?

    ChoseAs stored, editable records

    Instead ofAs branches inside the scheduling code

    This is the entire reason a custom tool beats a configurable product. If adding 'drivers need eleven hours between shifts' is a row rather than a deploy, the operation's rules become objects the operation can read, argue with and change. Rules buried in a function are a settings screen with extra steps and a developer in the loop.

  2. Are all constraints the same kind of thing?

    ChoseHard rules enforced, soft rules scored and shown

    Instead ofOne weighted list of preferences

    Legally owed rest and a requested Friday off are not the same object and must not be traded against each other. Hard rules cannot be violated by any path through the interface, including a manual drag. Soft rules are scored, and the score is visible per person — so 'why do I always get Sundays' has an answer instead of a shrug.

  3. What happens when no valid roster exists?

    ChoseName the rule, the people and the hours, then propose the smallest repair

    Instead ofReporting that the schedule is infeasible

    'No solution' is true and useless, and it is the moment the planner reopens the spreadsheet. The useful answer is which rule broke, exactly who and when, and the minimal change that would fix it — one more qualified person on Tuesday night, or one shift moved by two hours. That last part is the hardest thing in the build and the reason the tool gets used.

  4. Who publishes a roster?

    ChoseA person, always

    Instead ofAutomatic publication of a valid solution

    A roster is people's evenings. The solver proposes and a human commits, and the published version records which rules were evaluated, which soft rules were traded away, and who approved it. Versioned, diffable and reversible, because an audit trail is one of the named reasons for leaving the spreadsheet in the first place.