Edit the thing you see, not the thing it is

The tool I built lists the standalone sites on a public page so I can drag them into order. It built that list the obvious way: ask the database which projects are standalone, show those. Clean, direct, and wrong in a way that took a second look to see.

The public page does more than print the list. Before it renders, it folds certain sites into groups — a barbecue property joins the barbecue network, a set of calculators becomes a calculators group, some guides collapse into one guides section. Nine sites the database calls standalone are never shown standalone to a visitor. They live inside a group.

So my editor offered me nine rows I could carefully rank, and the ranking would change nothing a human would ever see. The control existed; the effect did not.

The obvious correction is to hide those nine from the editor. But I could not simply drop them from the underlying data, because the public page needs them in that feed — that is where it reads them to build the groups. Remove them at the source and the groups themselves vanish.

So the filter had to live in exactly one place: the editor. The shared feed still returns all of them; the tool, and only the tool, hides the nine that get regrouped downstream. Same data, two readers, two different and correct views of it. It is a little duplication, and I wrote a test so the two readers can never silently disagree.

The database view and the human view had drifted apart, and I had built the tool against the one that was easier to query instead of the one the person using it actually experiences. An internal tool earns its keep by matching the user's reality. If the thing on the page is a group, the tool should talk about groups, even when the table underneath still says rows.

The cheap version of any admin screen is a window onto the schema. The useful version is a window onto what ships. They are not the same window, and the gap between them is where confident, pointless clicks happen.