The fix list is an engineering problem, and it needs treating as one

Almost every avoidable delay in a certification has the same shape. The audit finds a set of website changes. The changes need engineering and copywriting time. That time belongs to a roadmap owned by somebody with different priorities, and the request arrives as a favour rather than as work.

Weeks later the file is still waiting on a page.

Why this specific work gets stuck

It is unglamorous, it is diffuse, and it is easy to postpone. There is no launch attached, no metric improves visibly, and each individual item looks like a ten-minute change, which is precisely why forty of them never get scheduled.

It also arrives from outside the delivery process. A list in a document from somebody in operations does not have a ticket, an estimate, an owner or a sprint, so it competes with work that has all four and loses every time.

Size it before you ask for it

Do the sizing work yourself rather than handing over a list of findings.

Turn each finding into a change with a location and a definition of done: this sentence, on this page, becomes that sentence. Group the changes by where they live, because forty copy edits across one template is a different job from forty across forty pages. Separate copy from code, since a lot of it needs no engineer at all if somebody has content management access.

A list arriving already estimated and grouped is a plan. A list arriving as findings is homework.

Sort it into three tiers

Blocking. The file cannot be submitted while this is live: claims that overstate what the product is, comparisons to approved products, a privacy policy standing in for a Notice of Privacy Practices, a page describing a model you do not operate.

Required, not blocking. Things that will generate a question but not a denial: vague provider descriptions, a cancellation route that works but takes five clicks, a disclosure in the wrong place.

Improvement. Everything the audit noticed that is not really about certification.

Only the first tier gates submission. Presenting all three as one list is how a two-week job becomes a two-month negotiation, and it is the most common self-inflicted version of the rework loop.

Give it an owner with the right authority

The person who owns the application needs to be able to get a change deployed without negotiating for it each time. Where that authority does not exist, the review will be slower than the file deserves, and that is worth knowing before filing rather than after the second request arrives.

In practice this means an engineering sponsor as well as a compliance owner: one person who can put the tier-one items into a sprint and defend them there.

Frame it as risk, not as compliance

Engineering leaders schedule work that has a consequence attached. "Compliance needs this" has no consequence in the room. "Card processing cannot go live until this ships, and the ad account is suspended meanwhile" does.

Bring the actual blockage: what is switched off, what it costs per week, and what the sequence is. Most teams reprioritise immediately once the dependency is visible, and most were never told.

Prevent the next list from existing

The fix list is a one-off. The mechanism that produced it is not, and without a change it refills at the rate the marketing team ships pages.

Two habits do nearly all of the work. The claims allowlist, distributed to everyone who writes copy, including agencies, freelancers and support. And one review step before a new landing page goes live, owned by a named person rather than by a committee.

Teams that adopt both ship faster afterwards, because the alternative is a legal review of every page by somebody reconstructing the reasoning from scratch each time.

Make it hard to undo

Two engineering practices are worth the small effort.

Put the compliance-critical copy where it cannot be casually overwritten: a shared component for the compounded-preparation disclosure, one source for the cancellation terms, a single privacy document link rather than five hardcoded ones. A sentence repeated across thirty templates will be corrected on twenty-eight of them.

And treat a redesign as a re-audit. Migrations recreate pages from design files rather than from live copy, which is exactly how corrected claims come back.

The items that turn out not to need engineering

A useful proportion of any fix list is content rather than code, and separating the two early is the cheapest scheduling win available.

Copy held in a content management system, FAQ answers, policy documents, email templates, support macros and product descriptions can usually be changed by whoever has access, today, without a deploy. So can advertising creative and affiliate briefs.

What genuinely needs engineering is narrower than it looks: hardcoded copy in templates, checkout and cancellation flows, consent and tag configuration, form logic, and anything requiring a new page or component.

Split the list on that line and hand the first half to a content owner the same afternoon. On most sites it removes half the items before the planning meeting starts, and it makes the remaining ask small enough to say yes to.

What to say in the planning meeting

Bring three things: the tier-one list, already estimated and grouped; the dependency, stated as what is blocked and what it costs; and the after: the allowlist and the review gate that stop this list existing again next quarter.

That is a fifteen-minute conversation with a decision at the end of it, which is a different meeting from the one where somebody circulates a document and hopes.