The PlayStation Portable test: why HTML-first design doubled a utility company's signups

There is a particular kind of failure that does not show up in your dashboards. It is the failure of absence, the user who arrives, encounters a blank screen or a spinning loader that never resolves, and leaves without a trace. Your analytics never record them because your analytics, too, depend on the JavaScript that failed them. A recent account from a developer who rebuilt a utility company's application form makes this invisible failure suddenly, vividly visible: when they replaced a broken React application with an HTML-first site, the number of people completing the form doubled overnight, and nobody in the analytics department could explain where these new users had come from. The answer, of course, is that they had been there all along.

The situation that produced this result is worth understanding because it is not exotic. The client was a regulated monopoly providing a public utility. Customers could apply for service through an aging ASP form or through a slower, more expensive manual process. The stakes were unusually concrete: if customer satisfaction dropped below a regulatory threshold, the company faced fines measured in millions of pounds. Two previous attempts to modernize the form had failed and cost a great deal of money. The most recent, a React application built by offshore contractors, survived three days in production before being withdrawn under a wave of customer complaints. It was, by the developer's description, a tangle of loading spinners and global JavaScript state, inaccessible to assistive technology, and it attempted to store uploaded images alongside all other form data in localStorage, a mechanism with a five megabyte ceiling that image uploads will breach almost immediately.

The argument beneath the rebuild

The decision to rebuild with Astro and a strict HTML-first discipline was not a stylistic preference dressed up as engineering. It followed from a small set of premises that, once stated plainly, are difficult to argue against. This is a public service. It should work on every machine possible. It should work when connections are poor. The forms must never lose data once it has been entered. Each of these is uncontroversial in isolation, yet the modern default of shipping a large client-side bundle before rendering anything quietly violates all four.

The developer draws on an anecdote from Terence Eden that deserves to be read in full, but its core is this. In a housing benefits office in London, a young woman sitting amid bags containing her possessions appeared to be playing Candy Crush on a PlayStation Portable. She was in fact reading the GOV.UK pages on housing benefit, connected to the office WiFi, on a browser that is slow, runs out of memory, and cannot hold more than three tabs. The pages worked because they are written in simple, lightweight HTML. They have to be. The design principle GOV.UK operates under, that the service is for everyone, is not a slogan. It is a constraint that shapes every technical choice downstream, and it is the same constraint the utility company should have been honoring all along.

How the rebuild actually worked

The technical pattern the developer adopted is old enough to feel novel again. Each step of the form wizard was its own page. Submitting a step posted the data to the API; if the data validated, the server redirected the browser to the next step. This is the post-redirect-get cycle that web applications were built on for years before the industry's center of gravity shifted to client-side rendering, and it has enjoyed a modest revival through frameworks like Remix that treat form submissions and HTTP semantics as first-class concerns rather than legacy inconveniences. The developer notes that the pattern took some explaining to colleagues accustomed to heavily client-side architectures, which tells you something about how thoroughly one approach has crowded out the institutional memory of the other.

The distinction being drawn is not that client-side applications are bad. It is that they are appropriate for a particular class of problem, and a multi-step government form is not in that class. A form is not a real-time dashboard. It does not need to maintain rich interactive state across a session in the browser's memory. When your user might be standing in a field on a new housing estate holding a decade-old Android phone bought from a supermarket, shipping twenty megabytes of JavaScript before rendering a single input field is not a neutral default. It is a decision to exclude people, made by omission.

The handling of state followed from the same reasoning. Each session received a unique identifier, and at every step the submitted data, including uploads, was persisted on the backend rather than hoarded in the browser. The payoff was concrete and slightly poignant: in one case a user returned to complete an application a full month after starting it, their data intact. The localStorage approach that doomed the React version could never have offered that.

Reclaiming validation from the libraries

The most instructive part of the rebuild concerns form validation, because it is where the philosophical argument becomes a measurable productivity claim. The developer argues, from more than twenty years in the industry, that teams routinely spend person-months wrestling with React validation libraries that amount to imperfect reimplementations of the validation system already shipping in every browser. Rather than fight that battle, they built a small HTML web component that wraps an existing form, reads the native HTML validation, and presents it well.

The component uses no shadow DOM and renders almost no HTML in JavaScript. It suppresses the browser's default validation tooltips and instead places error messages in the element referenced by the field, originally through aria-describedby, with aria-errormessage now the recommended attribute. It clears errors as the user types toward a valid state and re-evaluates on blur and on submit, which is precisely the rhythm a form needs. All of this fits in under a kilobyte. If the component fails for any reason, the form falls back to the browser's built-in validation; if that fails, the backend API validates. Three layers, each degrading gracefully into the next, so that errors are surfaced as early as the user's environment permits and never lost entirely. The developer has since rebuilt this as a general-purpose library called validation-enhancer, and the markup it expects is almost startling in its plainness: a validation-enhancer element wrapping an ordinary form, with standard inputs, native required attributes, and a div to receive the error message.

This is the heart of the progressive enhancement philosophy. The HTML is the application. JavaScript and modern CSS exist to improve the experience of using it, not to constitute the experience. The team targeted WCAG AA conformance, a pragmatic choice over the more demanding AAA, and the architecture made that achievable rather than aspirational, because accessible HTML is the starting material rather than something retrofitted onto a JavaScript-rendered interface.

What the doubling actually means

The headline result, a doubling of completed forms at launch, is best understood not as a gain but as the recovery of a loss. The previous architecture had been turning away roughly as many people as it served, and doing so silently. Those users existed on old browsers, on poor connections, on assistive technologies, and behind JavaScript that failed for reasons no error report ever captured. The analytics team's confusion about the source of the new users is the most telling detail in the entire account, because it demonstrates that the tools we use to measure success are built on the same fragile foundation as the products we measure, and they are therefore blind to exactly the failures that matter most.

There is a counter-perspective worth taking seriously, and the developer anticipates it. The replacement who inherited the project was, by the developer's account, appalled at the approach, objecting that supporting non-JavaScript paths was a lot more work. This is not an unreasonable thing to feel. Maintaining graceful degradation does impose costs; you are committing to a wider matrix of environments and a backend that must validate everything the client validates. The honest rebuttal is not that the work disappears but that it is the right work, and that the alternative does not actually eliminate the cost so much as transfer it onto users who have no way to complain and onto a company exposed to regulatory penalty. For a private product chasing a narrow, well-equipped demographic, the calculus might differ. For a monopoly delivering a public service, bouncing the marginalized user is not a defensible trade-off. It is a failure of the service's basic purpose.

The broader pattern this story points toward is a question about the maturity of software as a discipline. The developer frames the current moment as a continuation of the industry's wild-west phase, sustained by hype that rewards novelty over durability. The standard set out as a corrective is memorable precisely because it sounds absurd: build a web application that works on a PlayStation Portable over a 3G connection. The absurdity is the point. An application that clears that bar works for everyone, degrades sensibly when conditions are poor, and stands a real chance of still functioning thirty years from now, long after the framework it might have been built on has been deprecated, rewritten, and forgotten. The technologies that endure on the web have tended to be the simple, declarative ones, and the lesson of this rebuild is that betting on them is not nostalgia. It is, in the most practical sense, how you reach the people you were otherwise leaving behind.