A web developer says an HTML-first redesign doubled the number of customers completing an online utility application immediately after launch. The account describes a regulated monopoly whose users could apply through an old ASP form or a more expensive manual process, after two earlier replacement efforts had failed.
The latest rejected version was a React application that remained online for three days before customer complaints prompted its withdrawal. According to the developer, it depended heavily on loading states and global JavaScript state, did not meet accessibility needs and attempted to place uploaded images and other form information in browser local storage, which had a 5MB limit.
The replacement used Astro but treated JavaScript as an optional enhancement. Each stage of the form was a separate page. Submitting valid data to the server redirected the browser to the next stage, while invalid data remained subject to multiple layers of checking. This conventional request-and-response structure was chosen for people who might be using older Android phones over weak connections at new housing sites.
A small web component enhanced the browser’s native HTML validation. It suppressed default pop-up messages, placed errors in an accessibility-associated element and cleared or reassessed them as the user typed, moved away from a field or submitted the form. The component was under 1KB, the developer says. If it failed, native validation remained; if that also failed, the backend API still checked the submission.
The application kept session data on the server so progress did not depend on a particular tab or a fragile client-side store. One person reportedly returned and completed an application a month after beginning it. That persistence was part of a broader goal: preserve a usable path when scripts fail, networks drop or a browser has limited capabilities.
After launch, completed applications doubled. The organization’s analytics team initially could not explain the additional users, according to the case study, because JavaScript-based analytics had not recorded people who abandoned the earlier experience after script failures. The account does not provide raw traffic numbers, a controlled comparison or a breakdown of which design change caused the increase.
The result should therefore be read as one project report, not proof that HTML-first construction always doubles usage. The utility form had no need for constant real-time data, making server-led pages a particularly suitable fit. Its broader lesson is that progressive enhancement can make failure modes less final: a lightweight enhancement can improve the experience while the underlying form, browser controls and server validation remain available to every user.
