The bottleneck was never the digging.
Replacing a paper clearance process with one where the rules are enforced by the database rather than by remembering.
Clearance sets the pace
A utility contractor digs the holes for utility pole replacements. Crews and machines were never the constraint. Before anyone breaks ground a job has to clear underground-utility locates, environmental and cultural-resource permits, traffic-control plans, and inspections, and every one of those has an expiry date.
Run on paper and spreadsheets, that is not a scheduling inconvenience. A lapsed locate nobody noticed is a crew digging without authorisation, and the exposure that follows lands on the contractor, not on the spreadsheet.
Why this is harder than a checklist
Compliance here is not a list of boxes, it is a set of overlapping clocks. Each clearance has its own validity window, its own issuing authority, and its own renewal path. A job is releasable only in the window where all of them are simultaneously valid, and that window moves on its own every day, whether anyone is looking or not.
The other difficulty is quieter. What you are replacing is not a system, it is a set of habits that mostly work. Everyone knows which spreadsheet is current and who to call. Software that is merely more correct than that, but slower to use on a truck in the rain, loses to the habit and gets abandoned in month two.
What we built
Jobs and their audit trail. Every clearance a job needs, modelled as a task with an authority, a reference, a date issued and a date it dies, so the system knows what is valid rather than what was once filed.
Scheduling that understands clearance. Work can only be scheduled into the window where a job is actually releasable, and the schedule reacts when a clearance lapses rather than waiting for someone to notice.
A live map of every excavation point. Not a report of where crews were meant to be. The current state of every dig, colour-coded by where it stands.
Field logging built for a truck. Progress recorded where the work happens, on a phone, with gloves on and bad signal, rather than typed up that evening from memory.
The calls we made
Put the release rule in the application and it holds until someone adds a screen that forgets to ask. Put it in the database and no screen, no script, and no feature written next year can route around it. And guarding a gate is pointless if its inputs stay editable: a lapsed ticket whose dates can be bumped is a one-statement bypass of the entire model. So the dates a clearance rests on freeze the moment a job passes, and a correction takes an administrator who has to record a reason.
Who may see and change what is the kind of thing that gets deferred, because on day one everyone is trusted and it feels like overhead. Written in from the start it costs about half a day. Retrofitted, it means rewriting every access rule in the system late in the schedule, under a deadline, on code that already works. The cheap version of that decision is only cheap if you make it early.
A numbered set of rules governs the codebase, each with the reasoning that produced it. Breaking one is allowed. Breaking one quietly is not. A rule that lives only in the head of whoever wrote it is a rule that dies at the first deadline, and the client is left owning a system whose constraints nobody can name.
A locate is valid until a date. An inspection is a pass or a fail on a day. A permit is applied for, then pending, then granted, and can be pulled afterwards. Flatten all of that into one status field, which is what a general-purpose task tracker does, and you lose precisely the distinctions the release decision rests on. So each kind of clearance keeps its own lifecycle, and the gate reads each one on its own terms rather than asking a single question of all of them.
Where it is going
The data layer, the design system, and the first live screens are shipped and running. The rest of the feature work is tracked against the same documented dependency map it started from, and ships the way the first screens did: as independently reviewable pull requests, so the client can see what changed and why without taking our word for it.
A release gate is only as strong as the mutability of its inputs.
Anyone can build a checklist. Knowing that a locate expires on its own clock, that a cultural-resource permit answers to a different authority, and that the exposure lands on the contractor rather than the crew, is what turns a checklist into a release model.