HTML-First Rebuilt a Utility Form and Doubled Completions. The Users Were Always There — JavaScript Was Blocking Them from Getting Through.

The Play

The utility company's service application form doubled completions when it launched.

Not 5% more. Not 15% more. Double.

No new traffic. No paid campaigns. No A/B test or copy tweak. Just a rebuild.

The previous version was a React application. It lasted three days before customer complaints forced it offline. The issues: accessibility failures, loading spinners that blocked form progress, and an attempt to store file uploads in localStorage — which has a 5MB limit and broke silently for users uploading anything larger.

The rebuild used Astro with an HTML-first approach. JavaScript existed only as progressive enhancement. The form worked without it.

When it launched, completions doubled.

Then the analytics team found something revealing: they had not been tracking the full user population before. Analytics were JavaScript-based. Users who hit JS errors and bounced were never logged. The form was not failing for a few edge-case users — it was silently failing for a large portion of the population that was never reflected in the data.

Why This Matters for AI Tool Builders

This growth play is directly relevant to anyone building an AI product.

AI tools are among the most JavaScript-heavy products on the web. Complex React UIs, streaming response handlers, real-time editor components, OAuth authentication flows — it all depends on JavaScript executing correctly in every environment.

If any step in your signup or trial activation flow fails silently due to a JS error, an API timeout, or a browser extension conflict, that user is gone. Your analytics logs them as a bounce. You read it as low intent. The real explanation is that your form broke.

The users you lost did not leave because they did not want your product. They left because they could not reach it.

What to Audit First

Load your most important conversion page — signup, trial start, checkout — in a browser with JavaScript disabled. Does it render? Does the form submit? Does the user get any feedback at all?

Most AI tool signup flows show a blank page or an infinite spinner with JavaScript disabled. That is the failure mode you are looking for.

The second audit is more valuable: pull your server-side form submission logs and compare them to successful account creations in the same window. If the numbers are close, your form is working. If there is a large gap, users are starting and failing somewhere before submission.

If you do not have server-side logs for your conversion forms, that gap is invisible. You have been optimizing a funnel you cannot fully measure.

The Rebuild Pattern

Three principles cover most of the conversion improvement. This does not require a full rewrite.

Every form step POSTs to the server. Client-side state stored in React state or localStorage is vulnerable to refreshes, errors, and tab closures. When a user submits a form step, that data should live on the server immediately. One user in the original case study returned to their form a month later and completed it — that is only possible with server-side session persistence.

Forms work without JavaScript. Test this literally: disable JS and try to submit. If the form does not function, every user who encounters a JS error on your page cannot convert. That is a segment of real, interested users you are not counting.

Progressive enhancement for convenience, not function. Once the base form works without JS, use JavaScript to add validation feedback, file upload previews, step progress indicators, and autofill. These improve the experience for users with JS. They do not gate users without it.

Who This Applies To

The obvious targets are any conversion step with a meaningful drop-off you cannot fully explain.

For AI products specifically: trial activation flows that require email verification and a profile setup step. Onboarding wizards that collect use-case information before showing the product. Payment forms with dynamic pricing or usage tier selection. File upload flows for document analysis or processing tools.

Each of these is a point where a JavaScript failure silently removes a user from your funnel. And each is measurable from server logs — which most teams are not checking for this signal.

Measuring the Play

Track your form start-to-completion rate from server logs, not client-side analytics. Your server sees every request — your JavaScript tracking does not.

Compare that rate to the 30 days before the rebuild. Most products will see a 15% to 40% improvement on a critical-form rebuild. Some will see more, depending on how much silent failure was happening.

A 20% improvement in trial activation from users already on your pricing page is a better return than a 20% lift in paid traffic. You do not have to acquire those users again. You just have to stop the form from breaking before they get through.

Source: https://mohkohn.co.uk/writing/html-first/