Milestone Generator

Overview

A single-file scheduling tool that generates implementation timelines for post-payment solution rollouts, with the organization’s real deployment calendar built into the date math rather than applied by hand afterward.

It replaced a manual process that cost every project manager one to two hours per project and still produced dates the team regularly missed.

The problem

Every implementation needs a timeline. Each project manager built theirs by hand — one to two hours per project, often more, because errors tended to surface late enough that the whole schedule needed reworking.

The output was unreliable in a specific way: timelines were inconsistent between projects, dates were overpromised, and deadlines were missed. Not every day on the calendar is a day work can land, but counting through a calendar by hand to skip those isn’t necessary when the tasks in a timeline have standard durations.

Production deployments only go out after approval at a change advisory board meeting held Thursday mornings. Any task feeding a deployment has to be complete at least a day before that meeting. Miss it by one day and the deployment doesn’t slip by one day — it slips to the following Thursday.

So the cost of being slightly wrong isn’t proportional. It’s a step function: seven days, or nothing. Chain eighteen dependent tasks together — the length of the largest of the five timelines — each carrying its own gate, and holding that in your head while also doing the actual work of scoping a project is both a poor use of a person and an excellent way to produce a plan that looks right and isn’t.

The failure is also silent. A timeline with a bad date looks exactly like a timeline with a good one — right up until the date arrives and a client has to be told something moved.

Constraints

The rules weren’t written down. They existed, but not anywhere I could read them. They lived in the deployment calendar, in the change board’s meeting cadence, and in what each project manager had individually learned to do — which meant different people were working from slightly different versions of the same rules. So the first real task wasn’t building anything. It was getting the rules stated explicitly enough to encode: which review steps have fixed durations and which vary, what the change board requires and by when, which holidays the company actually observes, and where the five solution types genuinely differ rather than just having been done differently by different people. Most of this project’s value was created here, before any code existed. Writing the rules down is what made them checkable. The tool only made them executable.

Nothing installable. Any tool requiring a download, dependency, or package goes through an organizational approval process. A tool that needs approval is a tool nobody uses this quarter.

No mandate. Project managers decide how they build their own plans. Whatever I built would be adopted voluntarily or not at all.

It had to be checkable. The people I was asking to trust it had been doing this by hand for years. Output they couldn’t reconcile against their own reasoning would be output they wouldn’t use.

Nothing leaves the machine. The tool makes no network requests of any kind — no server, no API, no telemetry. The page is opened from a local file and everything it computes stays in the browser. That’s a stronger guarantee than a policy about what users should type into it, and it’s the reason the tool needed no security review.

Architecture

The distributed artifact is a single self-contained HTML file: form, scheduling engine, and output in one document a project manager opens locally in a browser. The source is split — markup, about 1,500 lines of scheduling logic, and a small build step that inlines one into the other — but nothing a user touches has more than one file in it.

The inputs are the facts a project manager already has at kickoff: which of the five solution types this is, when the ETL developer starts, when the initial load is expected to complete, and the date of the ETL transition call. Two solution types take one additional modifier — a remote-claims-access flag for Subrogation, a concept-development duration for COB and Data Mining.

Everything after that is derived. Nine to eighteen milestones depending on solution type, each placed by rule: working-day arithmetic, the holiday calendar, change-board gating, and task dependencies resolved in order.

What the tool deliberately does not do is estimate how long work takes. ETL development duration is an input, not an output — the project manager supplies it, because they’re the one who knows. The tool’s job starts after that: given a duration, compute when the work can actually land on a calendar that has weekends, holidays, and a Thursday gate in it.

That division is the design argument. Estimation is judgment and should stay with the person doing it. Calendar arithmetic is a rule set, and a rule set being executed by hand is exactly the kind of work that should stop being done by hand. The tool draws the line between the two and only crosses to one side of it.

No model runs at any point. A coding assistant built the tool; nothing generates anything at runtime. Every date is the traceable output of a rule.

“AI tool” would be the wrong description of what this is. The AI was in the building, not in the running.

Key decisions

Deterministic rules over a generative approach. A timeline is a commitment made to a client. A model that produces a plausible-looking wrong date is worse than no tool at all, because plausible errors are precisely the ones that survive review. The cost: the rules are maintained by hand. When durations or the calendar change, someone has to edit logic.

A single distributed file over anything installable. This was the constraint doing the design work. Zero dependencies means zero approval process, no security review, and no version pinned to one person’s machine setup — a project manager opens the file and it works. The cost: no central update path. A new version means redistributing the file, and no way to know who is still running an old one.

The change-board gate encoded as a hard constraint rather than absorbed by padding. The easier version adds buffer days and hopes they cover the gate. But buffer hides the rule: it inflates every timeline by the same amount whether or not the gate actually binds, and it leaves whoever reads the plan unable to tell which dates are real and which are cushion. Encoding the gate means the output sometimes looks more pessimistic than an optimistic hand-built plan — and is the date the work will actually land on.

Manual override that preserves the rules downstream. The first version had exactly one answer when a project manager’s judgment disagreed with the output: the tool wins. That’s a bad answer. Sometimes the PM knows something the rules don’t — a team is out, a client moved a review, a dependency landed early.

The current version lets them edit any date directly in the generated timeline. What it doesn’t do is stop enforcing rules. Changing a date cascades: every dependent milestone after it is recomputed under the same business-day, holiday, and change-board logic that produced the original. Edited rows are visibly marked as manually adjusted, and each one can be reset to its computed value.

This is the most important decision in the tool. The project manager’s judgment is respected exactly where they applied it, the rules still hold everywhere else, and the deviation is visible on the page rather than living in someone’s head. A hand-edited date in a spreadsheet silently invalidates everything downstream of it. Here it can’t — the downstream dates move with it, still obeying the Thursday gate.

Projects also save to browser storage and export to JSON, so a timeline can be reopened, adjusted as the project moves, and handed to someone else.

How it’s verified

There is no test runner. A console harness exists in the repo, with stated verification points, but it’s run by pasting into a browser console rather than by anything automated. Real verification was comparison, and it happened in two phases.

Before release, I ran the tool against work whose answers were already known: completed implementations compared to the timelines those projects actually followed, in-flight implementations compared to their live schedules, output structure checked against the standard project plan, and step-by-step comparison against hand-worked dates to confirm the gating logic fired where it should.

After release, other project managers checked it against timelines they had built or were building by hand — and their feedback caught errors my own checks had missed. Those reports drove most of the work that followed. The release history is largely a record of it: solution timelines rebuilt, durations corrected, milestones added that I hadn’t known existed.

The second phase was the more valuable one. The reviewers were people with years of intuition about these schedules, motivated to find the places the tool disagreed with them, and right often enough early on to matter. That’s a harder test than any assertion I could have written about my own logic.

With no automated checks, nothing catches a regression. A change to the scheduling logic is verified the same way the original was — by someone noticing.

Adoption and what changed

Nobody was required to use it. Project managers choose how they build their plans, so this was voluntary from the start.

It was released in December 2025 and won the organization’s monthly internal AI competition that same month, judged by the AI adoption team against submissions from across the company on use-case quality and hours saved. The award came first, on the idea and the hours it projected to save. Validation came over the following months, as other project managers put it against their own work and told me what was wrong with it.

It became the default for post-payment implementations across a group of roughly 11–20 project managers. The manual scheduling step went from one to two hours per timeline to effectively none.

The more interesting outcome was second-order. Colleagues started bringing me their own manual processes — one described it as having sparked ideas about how many other things could work the same way. The tool itself mattered less than what it demonstrated: that this class of problem was solvable by someone already in the room, rather than something to file a request about.

That changed how I look at other people’s work. Watching a colleague describe a workflow now mostly produces one question — which part of this is a rule that could simply be encoded?

What I’d do differently

The single-file decision solved distribution and created a versioning problem. There’s no way to push a fix, and no reliable way to know whether someone is running a stale copy.

I argued for a while that this was survivable at current scale — the group is small enough and uses the tool often enough that a change would reach everyone through the same conversations that reach me — and that it would stop being survivable when the tool extended to pre-payment implementations, roughly doubling the user base and adding a second rule set that could drift independently of the first.

Reviewing the code in September 2026, I found it had already stopped being survivable.

The holiday calendar had been written as a literal list of dates covering 2025 and 2026. It ended at Christmas 2026. Any timeline generated in the last quarter of 2026 that ran into the following year was computing business days across a 2027 with no holidays in it at all — New Year’s Day and Martin Luther King Jr. Day were being treated as ordinary working days. The tool would have produced those dates exactly the way it produces every other one: confidently, formatted identically, with nothing to distinguish them from correct output.

That is the precise failure this project was built to prevent, reproduced inside the thing built to prevent it. It went unnoticed for months because nobody re-derives a date the tool hands them. That’s the entire point of the tool, and it’s also why the error was invisible.

The fix was to stop storing the calendar as data and start deriving it. Holidays are now computed from their rules for any year — third Monday in January, last Monday in May, fourth Thursday in November, fixed dates shifted off weekends by the standard observance rule — with a small exceptions map for the years the company deviated from them. The computed output reproduces the previous 2025 and 2026 dates exactly, which is how I know the rules match what the list encoded.

That removes the single most likely reason anyone would have needed a new copy of the file: the calendar no longer expires. It does not solve versioning. Task durations still change — one release rebuilt all five timelines at once — and those still live in the distributed file.

The constraint that drove the original decision, no dependencies and no approval process, is real and I’d make the same call again. But there are two things I’d carry into the next version of this from the start.

The first is that a rule encoded as a list of its outputs isn’t encoded. It’s cached — and caches expire quietly.

The second is that “we’d all hear about it” was never a distribution strategy. It was an assumption that whatever went wrong would be the kind of thing somebody notices. The failure mode this tool exists to address is specifically the kind nobody notices.

Notes

Built and used internally, so there’s no public repository or demo. Everything described here is the design and the reasoning; no client-specific detail, internal system names, or proprietary scheduling data are included.