One hardcoded default, three places, two days: finding it once is not finding it

When you find a hardcoded default, search for the value everywhere before you close the work. The same regional default appeared in three separate places in our own product inside two days: the market detection in our free scan, the display logic in the report that scan produces, and the no signal fallback on our pricing page. Two of the three were wrong and have been changed. The third was right and should not be touched. Identical values, opposite verdicts, which is why a find and replace across all three would have fixed two problems and created one.

So the audit has two distinct jobs and they must not be collapsed into one. Finding every occurrence is mechanical and should be exhaustive. Deciding what each occurrence should be is a judgement that has to be made per site of use, by somebody who knows what that code is for.

The three occurrences, and why one of them was fine

Where	What it decided	Verdict
Market detection in the free scan	Which market a visitor's questions were run against	Wrong, and fixed
Display logic in the scan report	Which market the finished report said it had measured	Wrong, and fixed
No signal fallback on the pricing page	Which price ladder a visitor sees when nothing is known about them	Correct, and kept

The third survives scrutiny because the harm runs one way. A buyer whose handset ships with a foreign locale would otherwise be shown a ladder 2.2 times his own, and the default protects him from that. Falling back to the same region when deciding which market to measure is a different thing entirely: there the default silently produces a report about the wrong country, and no visitor is being protected from anything.

The lesson is not that defaults are bad. It is that the same literal value can be a deliberate protection in one place and a silent falsehood in another, and only the purpose of the code tells you which.

Why one default spreads through a product

• It was correct when it was written. A single market product has one right answer, and typing it directly is the obvious thing to do.
• It is correct in the environment every developer tests in. Nothing exercises the fallback locally, because a person building the feature always has the signals the detector reads.
• It gets copied forward. The next feature needs the same shape, somebody reads the existing function and writes a matching one, and the value travels with the pattern.
• It never throws. A default that renders is not an error anywhere. Nothing is logged, nothing fails, and the wrong answer looks exactly like the right one.

Those four together explain why the count is almost never one. By the time anybody notices, the value has been correct for long enough to be unremarkable and copied often enough to be plural.

How to search for the other occurrences

• Name the exact value first, in writing. Not a description of the behaviour, the literal thing: the country code, the currency string, the constant.
• Search for the value, its synonyms and the constant that holds it. A country can appear as a two letter code, a full name, a currency symbol and a named constant, and a search for one of the four finds a quarter of the problem.
• Search in the places that are not code. Configuration files, environment defaults, database column defaults, seed data and style tokens. One of our own silent failures that fortnight was a style fallback naming a token that did not exist, which painted a set of statistic tiles white.
• List every hit with its purpose beside it, then classify each one as correct, wrong, or needs an owner. The third category is legitimate and it is where the useful conversations happen.
• Print the count. If your search found one occurrence, say so explicitly, because one is a surprising answer and worth doubting.

The pattern of a value that is right in one context and wrong in another, on a site selling into more than one market, is worked through from the buyer's side in our page on one site, two currencies and the pricing page.

A flag that names a reason is not a list of reasons

There is a second habit this cost us, and it generalises further than the default did. One of our stored page bodies carried a staleness flag, and the flag named one defect. We fixed that defect and treated the file as handled. The file was behind on something else as well, and pushing an update built from it quietly restored a sentence that had already been corrected on the live page. The word count went up, so the guard watching for lost content passed it.

A flag tells you that something is wrong. It is not an inventory of everything that is wrong, and a flag with one reason attached is the easiest thing in the world to read as complete. When you find a marker like that, rebuild from the source of truth rather than patching the thing the marker pointed at. The ways this class of problem stays quiet inside an internal build are catalogued in our page on build or buy for an AI visibility stack.

Questions about auditing for a default you have already found once

Why not fix all the occurrences the same way?

Because they are not the same decision. Two of our three were producing a wrong statement about a market and one was protecting a specific buyer from a price he should not see. A uniform change would have broken the one that worked.

How do I know when I have found them all?

You do not get certainty, you get coverage you can state. Search the value, its synonyms, the constant, configuration, seed data and styles, then write down what you searched and what you found. A stated search is reviewable; a feeling is not.

Should defaults be removed entirely?

Removing them replaces a wrong answer with a crash, which is sometimes right and often worse. The better move in most cases is to keep the default, document who it protects, and make the alternatives available in the document so the default stops deciding what anybody can learn.

How did a wrong market default get as far as a customer report?

Because it was correct for most of the people looking at it, which is the general mechanism. A default is only visible to whoever it is wrong for, and they are rarely in the room.

What is the single check worth adding afterwards?

One that states the expected answer rather than comparing two readings. A check requiring three named markets each to show their own currency catches this class of thing on one request and names the failure.

The verdict is per occurrence and the search is not

Two days, three places, two fixes and one deliberate decision to leave something alone. The ratio is the finding: a defect found once is a sample from a population you have not counted yet, and the counting is cheap while the consequences of skipping it are not. We keep the record of which of ours were wrong, which was right and on what date each was settled, in the same place as the numbers we are proud of, and the exports, windows and dated blind scan behind our published claims are on our proof page. Doing this kind of sweep inside other companies' sites, and telling them which occurrences to leave alone, is part of what we are hired for.