Remediation in weeks, with your assumptions showing

An estimate is a claim about a team size, a scope and a sequencing you have assumed — print those assumptions beside the number, because the number will be wrong and the assumptions are what make it correctable.

Every amber and red on the page is now a claim that somebody has to fund work. The reader’s next question is immediate and unavoidable: how much. Answer it badly and the whole page loses its standing, because a colour with no quantity behind it is the observation you already agreed to delete.

The trap is that estimating feels like the part of this you already know how to do. You have sized front-end work for years and been roughly right. What is different here is that you are sizing somebody else’s codebase, which you have mostly not seen, to be executed by a team you have never met, on a schedule set by a transaction. The number will be wrong. The job is to make it wrong in a way that someone with better information can fix.

An estimate is a conditional, not a measurement

Write the sentence out in full once and the structure is obvious. It has the shape given this many engineers who already know this codebase, working on this and nothing else, with the framework upgrade finished first, this takes somewhere between these two numbers of weeks — and the numbers are yours to fill in from the target in front of you, because nobody has published a duration you could borrow. Every clause before the number is load-bearing. Strip them and you have not simplified the claim, you have made it unfalsifiable — and an unfalsifiable number cannot be corrected, only believed or disbelieved.

Which is the practical argument for printing the assumptions, and it is stronger than the honesty argument. The reader knows things you do not. They know what the team actually looks like, whether the two engineers who understand the build system are staying, and what else is on the roadmap. Printed assumptions let them replace yours and recompute. Printed assumptions turn your estimate into a model they can operate. Hidden ones turn it into an opinion they can only accept or reject.

There is no benchmark to reach for

When you go looking for how long this kind of work usually takes, you will find numbers, and every one of them will come from a firm quoting for the work on its own marketing page. There is no independent survey, no professional body collecting data, and no peer-reviewed literature on remediation durations for front-end work.

So there is nothing to anchor to and you must not invent an anchor. A framework upgrade does not take a standard number of weeks. A design system consolidation does not have a typical duration. If you write one down as though it were known, the first practitioner who reads your page will ask where it came from, and there is no answer.

What the published sources actually give you

They give you the form, and the form is worth having. A data-room vendor publishes a worked report that prices individual findings in engineer-months and totals them. A firm selling the reviews lists among its deliverables a remediation roadmap with cost and timeline estimates. An openly readable checklist on GitHub, with no stated licence and no visible date, carries a remediation guide mapping findings to specific fixes, which is the closest published model for this half of a scorecard.

Read all three for shape and none for content. What they establish is that a finding arrives with a quantity, that the quantities sum to something, and that the sum is a deliverable in its own right. What they cannot establish is any particular quantity, because none of them is reporting a measurement.

Effort and duration are different numbers

This is where estimates most often break, and it breaks in a way the reader will not catch, which makes it your responsibility rather than theirs.

Effort is engineer-weeks: how much work exists. Duration is calendar weeks: how long before it is done. They convert into each other only under assumptions you have to state. Twelve engineer-weeks of work, given three engineers who can all work on it at once, is four calendar weeks. Given three engineers where two of them are blocked until the first finishes the migration, it is not four calendar weeks, and the arithmetic that produced four was hiding a parallelism claim nobody wrote down.

Sequencing does the same thing at the workstream level. Two workstreams you sized at eight weeks each are sixteen calendar weeks if they both need the one engineer who understands the build pipeline, and eight if they genuinely run side by side. That is a factor-of-two difference produced entirely by an assumption, and the reader cannot see which one you made unless you print it. So print it: which workstreams run in parallel, and what makes that possible.

Group into workstreams before you estimate

Estimating question by question triple-counts. Upgrading the framework, turning on strict typing and clearing the dependency backlog are three separate ambers on the front-end debt axis, and they are one piece of work: the same team, in the same branch, sharing the same setup, the same regression sweep and the same release. Priced separately, that setup gets paid for three times and the total comes out inflated in a direction that is easy for a hostile reader to attack.

So the assembly order is fixed. Take only the ambers and reds — a green that generated an estimate was not green. Group them into workstreams by who does the work and when, not by which axis they came from. Then estimate the workstream, state its assumed team, and state what has to finish before it starts.

Give a range rather than a point. A point estimate drawn from partial, outside-only evidence is a false claim about your own certainty, and the width of your range is real information — a two-to-three-week range and a six-to-twenty-week range are telling the reader completely different things about how well you could see.

Retrieval check

You marked a question red because the size of the remediation is genuinely unknown, not because it is large. What number goes in the estimate?

Check your answer

Not a number. A red that means “unbounded” is precisely the case where inventing a range does the most damage, because the range will be read as your judgement of the scale and it is not: it is your judgement of your own ignorance, dressed as a quantity.

Write what the row is actually for instead. Name the work that would be required to size it — a day with the codebase, a conversation with the two people who built it, an export of the component inventory. Put weeks on that, because sizing work is work you can size. And say plainly what makes the underlying scope unknown.

This is a stronger line than a fabricated range and it reads that way in the room. “Three days of access would let me put a number on this, and until then the exposure is open-ended” is an actionable request. A made-up range is a hostage to the first person who asks how you got there.

The line they will remember

The assumptions block in the rubric ends with a question that looks like an afterthought and is not: what would make this estimate materially worse?

One sentence. The two engineers who wrote the design system are the two the deal is expected to lose. The upgrade path assumes a component library that is still maintained. The consolidation assumes nobody insists on preserving the old screens for a large customer. Each of those is a single condition that, if it flips, changes the number by more than your range covers.

Six months after the close, when it flips, that is the sentence somebody goes back and finds. It is the cheapest credibility available in the whole document, and it costs you a line.

Hands on

Build an estimate somebody else can correct

Done when: RUBRIC.md has a remediation table where every row is a workstream rather than a question, carries a range, an assumed team and a sequencing statement, and the assumptions block underneath is filled including the materially-worse line.

Open learning/ux-diligence/RUBRIC.md and pull out only the ambers and reds. If any green produced work, go back and fix the colour first — that is a scoring error, not an estimating one.
Group them into workstreams by who would do the work and when. Expect the groups to cut across axes; a design-system consolidation will pick up questions from UX maturity and front-end debt at once. Name each workstream in the language the work would actually be described in.
For each workstream, write the effort in engineer-weeks first. Then write the assumed team. Only then compute duration in calendar weeks, and write the parallelism assumption you used to do the conversion.
Turn every point estimate into a range. Then look at the widths: a range you cannot justify the width of is a range you guessed. Note beside each what evidence would narrow it.
State the sequencing explicitly. Which workstreams can run at once, and what shared person or shared system stops the others from doing so. Add up the critical path and check it against the total you would have written without thinking.
Fill the assumptions block: team size, what is in scope, what is explicitly out of scope, the sequencing, and the one line naming what would make this materially worse. Out-of-scope is the one people skip and the one that stops the estimate being quoted back at you for work you never priced.
Bring the estimate into the chat with the assumptions block. I will change one assumption and ask you to recompute — if the number cannot move in response, the assumptions were decorative.

What this does not cover

A well-assembled estimate makes disagreement more likely rather than less, and that is the intended effect. The moment you attach weeks to a finding, the management team has something concrete to push back on, and at least one of them will — usually the one whose area you priced.

The lesson on the finding they will dispute is about that moment: how to write the finding so the argument lands on the evidence rather than on your judgement, what the severity of a disputed finding actually changes in a deal, and why declaring in advance what would change your mind is the strongest position available to you. After it, the last lesson runs the whole instrument against a real product you can only see from the outside.