The utility scheduler no off-the-shelf product could build

Every off-the-shelf scheduling product makes the same quiet assumption: that your constraints are independent. Assign the crew, then check the permit, then check the location, each rule evaluated on its own. That assumption holds for simple scheduling, and it’s why those products exist and sell.

It falls apart the moment your constraints interact — when satisfying one changes whether another can be satisfied at all. That’s the situation this project started from, and it’s why no product could build it. The answer wasn’t another subscription. It was a custom constraint-optimization engine, and it reached 96% workday efficiency across more than a dozen interacting constraints.

The problem: constraints that talk to each other

Utility field work is a scheduling problem disguised as a logistics problem. On any given day you’re placing crews against jobs, and the rules aren’t a checklist — they’re a web:

• Geospatial separation. Certain work can’t happen too close to other work at the same time, for safety and regulatory reasons. Where you place one job constrains where you can place others.
• Per-block permit status. Every address in a block carries its own permit state, and a job can’t start until the relevant permits across the block clear — a combinatorial constraint all on its own.
• Permit lead times. A job isn’t schedulable until its permit clears, and permits have variable, sometimes unpredictable lead times. The calendar bends around paperwork.
• Crew skills and certifications. Not every crew can do every job. The eligible set changes per task.
• Travel and routing. Crews move through physical space; a schedule that ignores travel is a schedule that doesn’t survive contact with the morning.
• Equipment availability. Shared, finite resources that two jobs can’t both use.
• Time windows. Hard start/finish boundaries on individual jobs.

…and that’s the short list. Counting the sub-rules each of these expands into, the engine juggles more than a dozen interacting constraints at once.

Each constraint is manageable alone. The difficulty is that they’re coupled. Move one job to satisfy a spatial-separation rule and you’ve changed the travel pattern, which changes which crew can reach the next job in its time window, which interacts with a permit that won’t clear until Thursday. A human scheduler holds maybe a few of these in their head at once and satisfices. A rules engine checks them in sequence and produces something legal but wasteful — lots of idle time, lots of crews driving across the service area for no reason.

Why off-the-shelf products can’t do this

SaaS schedulers are built for the common case: independent constraints, evaluated one at a time. That’s a deliberate design choice — it keeps the product general and the UI simple. But it means the product literally cannot reason about constraints together. It can tell you a schedule is legal. It can’t search the enormous space of legal schedules for the one that wastes the least time, because it doesn’t model the interactions that make one legal schedule far better than another.

You can feel this when a product “almost” fits and you find yourself doing the real optimization by hand in a spreadsheet next to it. That spreadsheet is the tell. It means the hard part of your problem lives outside the tool, and you’re the solver. That’s the moment to stop shopping and start building — not because custom is always right, but because this specific shape of problem is what operations research exists for.

The build: constraint programming, kept lightweight

The engine models the day as a constraint-satisfaction and optimization problem. Jobs, crews, time, and resources become variables. The rule families become constraints over those variables. The objective is workday efficiency — minimize idle and wasted travel, maximize productive on-site time — subject to every hard constraint holding simultaneously.

The solver then does what a human and a rules engine can’t: it reasons about the constraints jointly and searches for an assignment that satisfies all of them while optimizing the goal. When a permit pushes a job, the engine doesn’t just flag it — it re-plans the surrounding work so the day stays dense.

Two engineering decisions kept this practical rather than academic:

Lightweight libraries over heavy platforms. This was built with compact Python solver libraries, not a sprawling enterprise optimization suite. The problem was hard; the deployment didn’t need to be.

Serverless deployment. Because the footprint was light, the whole thing runs serverless — it spins up to compute a schedule and spins down. No always-on infrastructure, no heavy operating cost for a tool that’s invoked when the schedule needs to change. Operations-research-grade results on commodity infrastructure.

The result: 96% workday efficiency

The number that matters is 96% workday efficiency — the share of the workday spent on productive, on-site work rather than idle time, avoidable travel, or schedule churn. Across more than a dozen interacting constraints, the engine consistently produced schedules a human couldn’t match and a product couldn’t compute, and it did it cheaply enough to run on demand.

That’s what “go beyond off-the-shelf” actually looks like. Not a flashier dashboard. A solver that does the part of the job the products quietly hand back to you.

The operator read

The instinct when scheduling gets painful is to shop for a better scheduler. Sometimes that’s right. But if you notice your constraints interact — if satisfying one routinely breaks another, if there’s a spreadsheet next to the tool where the real planning happens — you’re not looking at a product gap. You’re looking at an optimization problem, and optimization problems are built, not bought.

This is the least glamorous and most defensible kind of work I do: a problem with real mathematical structure, solved with the right method, deployed without waste. No model in sight — just operations research applied where it actually pays.

If your scheduling, routing, or allocation problem has that interacting-constraints smell, tell me what’s broken. If a product can solve it, I’ll point you at the product. If it can’t, I’ll build the thing that can.