Every product that stores things eventually has a screen listing them, and that screen is almost always designed against a demo dataset. Twenty rows, all recent, all created by the person looking at them. It’s a perfectly good design for that. The trouble is that nobody uses the product at twenty rows for very long — the customers who matter are the ones who kept using it, which means the customers who matter are precisely the ones for whom that screen stopped working.

The failure is gradual enough to go unnoticed internally. At a few hundred items, people scroll a bit more. At a few thousand, they start using the browser’s find-in-page, which only searches what’s already loaded. Past that they stop trying to find things and start remembering where things are, or keeping a separate note of the ones they care about, or just re-creating something rather than locating the copy that exists. By the time anybody files a ticket, the workaround has been habit for a year, and the ticket says something vague like “the list is slow” when the actual complaint is “I can’t find anything.”

Which is why finding is worth treating as a first-class feature rather than a row of controls added above the table. The distinction is whether someone owns the question “how does a person with eleven thousand of these locate the one they want,” and whether the answer has been tried with eleven thousand of them. Filters that only apply to the current page aren’t filters. Sorting that only orders what’s loaded is worse than no sorting, because it looks authoritative. Both are common, and both come from building against a dataset small enough that the difference doesn’t show.

There’s an ordering question underneath, and it’s a product decision people leave to the database. Newest-first is the usual default and it’s often wrong: the things a person needs are the ones they touched, the ones assigned to them, the ones with something pending. Defaulting to recency means everyone’s first screen is dominated by whatever the noisiest process in the system created most recently, which in a mature account is usually automated. A default that reflects what the viewer is likely to want is more work and it’s the difference between a screen people use and a screen people scroll past on their way to search.

The other half is the count. Showing a total is trivial at small sizes and expensive at large ones, and the usual resolution is to keep it and let the page get slow — because it’s already in the design, and nobody wants to be the one who removes a number. But an exact count is rarely what anyone needed: they needed to know whether they’re looking at all of it, and roughly how much more there is. “About 12,000” answers that. Deciding this deliberately is much better than discovering it as a timeout on the account you least want to have problems.

None of this is architecturally deep. It’s the same lesson the limits thread and the notifications thread kept arriving at from other directions: a design that’s sensible for a small amount becomes unusable for a large one, and the transition happens quietly, at the customers you’d least like to lose.