---
url: "https://dfylegitscript.com/blog/getting-the-website-fix-list-through-your-engineering-team"
title: "The fix list is an engineering problem, and it needs treating as one"
description: "The claims audit is the longest piece of work in most LegitScript applications, and its output is a list of website changes owned by people with a roadmap, which is why a certification timeline is usually decided by a sprint planning meeting nobody invited compliance to."
published: "2026-08-02T15:18:23+00:00"
modified: "2026-08-02T15:18:23+00:00"
---

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

The claims audit is the longest piece of work in most LegitScript applications, and its output is a list of website changes owned by people with a roadmap, which is why a certification timeline is usually decided by a sprint planning meeting nobody invited compliance to.

## Key takeaways

- The fix list is an engineering problem, so a certification timeline is usually decided in a sprint planning meeting nobody invited compliance to.
- Size the work before you ask for it, because an unestimated list of changes competes badly against a roadmap where everything else carries a number.
- Sort it into blocking, required and improvement, and be honest that only the first tier actually gates filing.
- Frame it as the blockage it is, since payments, advertising and partnerships are waiting on these pages, which is a different conversation from a compliance request.
- Around half of a typical list needs no engineer at all, because it is copy in a CMS, a link in a footer or a document nobody has replaced.

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](/blog/the-rework-loop-that-stalls-self-filed-applications).

## 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](/blog/rebranding-or-migrating-a-certified-telehealth-domain).

## 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.

## Frequently asked questions

### How long does the website work usually take?

It is the long pole in most applications, and the elapsed time is set by scheduling rather than by difficulty. A grouped, estimated list of blocking changes is often a few days of actual work sitting behind a queue that is measured in weeks.

### Do all the audit findings have to be fixed before filing?

No, and treating them as one list is what stalls the work. Only the changes that would generate a denial or a certain request for information gate submission. The rest can ship afterwards, provided somebody owns them.

### How do I stop the same problems coming back?

A claims allowlist distributed to everyone who writes copy, and one named person who reads new landing pages against it before they go live. Without both, the list refills at the rate the marketing team ships pages.

## Disclaimer

LegitScript is a trademark of LegitScript LLC. VeriScripts is an independent application-preparation service. It is not affiliated with, endorsed by, or certified by LegitScript LLC, and claims no sponsorship or partnership with it. We prepare, submit, and manage the application; LegitScript alone decides whether certification is granted. "LegitScript" is used here only to name the certification these applications are for.