There is no reliable way to attach a percentage to engineering work that was never measured, and inventing one to satisfy generic "quantify your impact" advice is worse than leaving the number out, because a fabricated statistic is either wrong or impossible for you to defend if someone asks how you got it. What can be described honestly, even without a tracked metric, is scope: how large the system was, how many people or services depended on it, how often it ran, and what measurably changed between a before state and an after state. Those are facts you can usually reconstruct from memory, a ticket history or a postmortem, and they read as far more credible to a hiring manager than a number that appeared from nowhere.
Why "just add a number" advice falls apart without a metric
Most CV advice tells engineers to quantify every bullet, and the advice is not wrong on its own terms: a reader scanning dozens of CVs genuinely responds better to something concrete than to a vague claim. The trouble is that a lot of real engineering work was never tracked in a way that produces a clean percentage. Plenty of teams do not run a dashboard for every change, plenty of impact is felt rather than measured, and plenty of engineers move to a new role before anyone circles back to check whether last quarter's change actually helped. Faced with that gap, the tempting shortcut is to write a number that feels roughly right and hope nobody asks where it came from. That shortcut is exactly the trap this post is about avoiding, because a number an interviewer can pull apart with one follow-up question does more damage than no number at all.
Honest measures that exist even without a tracked metric
Several kinds of concrete detail exist for almost any piece of engineering work, whether or not a metric was ever recorded for it. Scope describes the size of what you touched: the number of services a change spanned, the size of the codebase, the number of endpoints or tables affected. Scale describes how much the system carried: how many requests it served, how many records it stored, how many teams built on top of it, described in terms you can state confidently rather than a figure you are guessing at. Frequency describes how often something ran or was used: a batch job that ran nightly, a deploy pipeline used by every engineer on the team, a report generated for every closed quarter. Before-and-after state describes what was true before your change and what was true after it, in plain language rather than a percentage: what used to fail, what used to require a manual step, what used to need someone on call, and what stopped being true once the work shipped. Who relied on it names the actual audience: the team that used the tool you built, the service that called the API you maintained, the on-call rotation that no longer got paged for the issue you fixed. Every one of these is something you were actually present for and can describe from firsthand knowledge, which is exactly what makes it defensible in a way a rounded-up percentage is not.
Illustrative example: a bullet rewritten around scope instead of a percentage
Before, vague and unquantified: "Responsible for the checkout service's performance." After, rewritten around scope and a described before-and-after state rather than an invented number: "Owned the checkout service's database query layer, the single path every purchase on the site went through; before the rewrite, slow queries were the most common cause of a stalled checkout that the support team escalated, and after it shipped, that category of complaint stopped appearing in the weekly triage." Nothing in the rewritten version is a guessed statistic. It states what the candidate owned, how central that piece was to the system, what the problem looked like beforehand, and what changed afterward, all from something the candidate actually witnessed rather than a number reconstructed after the fact.
What to leave out of the rewrite
The line to hold is between a number you can currently point to, from a dashboard, a postmortem, or a metric you genuinely tracked at the time, and a number you are reconstructing from a vague memory of "it felt like things got a lot faster." The first is fine to quote directly. The second is the one worth rewriting using scope and before-and-after language instead, because a remembered impression rounded into a clean-sounding figure is exactly the kind of claim that falls apart under one specific follow-up question in an interview. The scope-based version above survives that question, since every part of it is something you can describe in your own words without relying on a number you never actually recorded.
Where this fits with the broader duties-to-achievements pattern
Rewriting around scope instead of an invented statistic is one specific application of a wider shift that applies well beyond engineering: turning a description of what you were responsible for into a description of what actually changed as a result. Turning duties into achievements on your CV covers that broader rewrite pattern with examples from roles outside engineering, for anyone whose bullets currently read like a list of assigned tasks rather than outcomes.
Building the entry
How to write a resume covers the wording choices that carry this kind of rewrite through the rest of a CV, and CVBuilderKit's developer template is built around exactly this kind of scoped, project-led entry. Start from an existing document or a blank one in the builder and rework each bullet using scope and a described before-and-after state before reaching for a number you cannot actually stand behind.