A hundred kilobytes is not a large file. It is a very large answer to a question one screen asked once, and it arrives at that size because nobody ever decided what the screen was allowed to keep.
A European retail and private banking group had a front-office advisory application built for it by an outside supplier. An independent technical assessment read the delivered build one quality area at a time, tying what it found to items in the shared issue tracker, to written observation where no tracker item carried the point, and in one area to a measured figure. Under performance, the reviewer wrote the sentence the rest of this turns on: data model management in the front end was the biggest problem in the application, and there was no consistent concept for the management of data. Data moved through a web API. Packages of up to 100KB were being sent across the wire, with very inefficient resource management and caching problems throughout.
The challenge
The payload figure is the part that gets attention in a steering meeting, and it is the least interesting thing on the page. A hundred kilobytes in one package is a consequence. What produced it was an absence: no agreed answer to what the client held, how long it held it, and who was allowed to throw it away.
Read the rest of the finding and that absence appears in every symptom listed beside it. Problems with immutable objects were widespread. Refresh logic was complicated. Two items were logged behind the finding, one for modularisation and one for repeated calls, and over-fetching was recorded separately in the data area, against a tracker item of its own. None of those is really a distinct defect. They are the same missing decision seen from different screens. If nothing owns the client's copy of the data, every screen has to fetch what it needs, no screen can trust what another one already has, and caching becomes a per-screen habit rather than a policy.
The caching evidence makes the point in an unusual way. Two caching defects were logged on the best-practice page of the same review, and the written finding beside them was never drafted at all: that page carries four category headings with dashes after them and no text under any of them. The tracker knew. The narrative had not caught up.
The reviewer was candid about the limits of his own pass. He ranked front-end data management as the biggest problem in the application, then closed the paragraph with a line saying it was a large topic that still needed code-level findings, written in the colour he used elsewhere for items awaiting verification. An unexplained figure sits at the end of that same paragraph and nothing in the material says what it counts. So the most severe item in the review is also the item with the least evidence written up behind it, which is what a time-boxed human pass produces when severity and effort get decided separately.
The approach
The server side had the same problem in a different dialect. Hundreds of classes were very large and responsible for many actions at once, many controllers ran to two thousand lines, and one cyclic dependency made layer separation impossible, which the reviewer said left the codebase monolithic. Both halves were failing the same way: no boundary that anyone had agreed to hold.
What this engagement produced was findings and recommendations. It rebuilt nothing, and it is worth being plain about that. Only one remediation is recorded anywhere in the pack: front-end race conditions and server-side static variables, which the same sentence calls easily identifiable, were fixed by the group's own IT organisation a few months after the build under review. Nothing structural carries a fix note. What got repaired was what was cheap to spot, which is the ordinary bias of any review that has to be read before it can be acted on.
The repair that would have mattered is not a refactor. It is a decision, and it fits on one page. Name the owner of client-side state. Declare what the front end may hold and for how long. Say who invalidates it, and on what event. Then make every screen read from that instead of from its own fetch. Payload size stops being a mystery at that point and becomes a measurable consequence of a rule somebody signed.
This is where an assessment turns into something we sell. Deciding to own client state takes an afternoon. Discovering what the existing screens actually hold, which calls are redundant, which refresh paths contradict each other and what breaks when a shared model replaces them is a build, and it is where the Platform work starts.
The outcome
Test coverage went the same way as the data model. Server-side coverage was measured at approximately 14 percent. Front-end coverage could only be estimated, most probably below 10 percent. Most of the tests that did exist checked for null values and lengths rather than for content, so the assurance was thinner than the percentage suggested. Both figures carry a caveat the source itself supplies: the reviewer left that entire passage in his unresolved colour, so the 14 percent is measured but not signed off. Note what that leaves. The half of the application holding the undecided state was also the half nobody had measured.
Years of front-end fashion have not changed the arithmetic. They have raised what it costs. The same advisory screen is now expected to carry a copilot beside the advisor, and every pattern in that sentence depends on a dependable answer to what the screen currently holds. Retrieval-augmented generation grounds an answer in documents; it does not ground it in the position the advisor is looking at. An agent loop that reads session state and proposes a next step needs that state to mean one thing. Graded autonomy is a hand-off, and a hand-off needs a defined object to hand over. An evaluation set is only reproducible if its input is, and two screens holding different versions of the same holding make the input unreproducible by construction.
The same review logged four exception-handling defects across three named failure modes, one of which was error swallowing, and left its logging page entirely blank, so nothing in the material says whether logging was clean or simply never examined. In advice, a swallowed error produces a screen that looks like it worked. Put a copilot on top of that screen and it will reason confidently on a result that quietly failed. Under the EU AI Act, now in force, and under any bank's own model risk management, the obligation is to be able to show afterwards what a system presented to a person and what it presented it on. That obligation is served or defeated by exactly the decision this review found missing. Our Consult engagements now open on that question rather than on the model, because a system that cannot say what it was holding cannot evidence what it advised.
The size was never the problem. A hundred kilobytes was the size the review put on the largest packages, on a build that was already several months old by the time it was written up. The problem was that no one had decided what the front end was allowed to hold, and every number in the performance section turned out to be a different way of measuring that one missing decision.