When I rebuilt my video downloader as plain PHP pages, I spent more time on where the Download button sits than on almost anything else. That sounds wrong until you remember what a single-purpose tool site is: one input, one button, one result. If any of those three is in the wrong place, the whole site feels broken.

Here are the small decisions I ended up with, and the mistakes that forced each one.

The button lives directly under the input

My first layout put the URL field and the button side by side, like a search box. It looked tidy on desktop and awful on a phone. The field shrank, the button shrank, thumbs missed. Worse, on narrow screens the button wrapped underneath anyway, so I had two layouts to maintain for no reason.

Now the input is full width, and the button is full width directly below it. Big, thumb-sized, impossible to miss. One layout, every screen. It is the least creative decision on the page and the one I would change last.

Paste does not mean start

Early on I had the resolve start automatically when the clipboard content looked like a video URL. It felt clever for about an hour. Then I realised every pasted link spent a provider API call before the person had even decided they wanted to download it. Mistyped URLs, wrong-platform URLs, accidental pastes — each one burned quota.

So now nothing happens until the tap. The button is the commit point. It is slower by one tap and cheaper by every accidental request.

The button says what will happen, then says what is happening

A tool button should never just say "Submit". Mine says "Download" at rest. The moment you tap it, it disables itself and says "Getting video...", and it stays disabled until the request finishes. This killed two real problems: double-taps firing two API calls, and the classic "is it doing anything?" tap-rage where someone hits it five times.

The honest text matters too. I used to show a spinner with no words. People read a spinner as "broken" after about three seconds. "Getting video..." with a disabled button reads as "working".

Errors land where the action was

When a resolve fails — private video, deleted post, provider busy — the error message appears directly under the button, not in a toast at the top of the screen and not in an alert box. The message is plain: "This video looks private or deleted," not "HTTP 404 from upstream provider". Nobody on a downloader site knows what an upstream provider is, and they should not have to.

The button re-enables with the same label it had before. No page reload, no lost URL in the field. The person can fix the link and try again without starting over.

Quality options get sorted, not dumped

After a resolve succeeds, the results list the available formats best-first, each labelled with what it actually is: "MP4 720p (with sound)", "MP4 360p (with sound)", "Audio only (M4A)". No raw file sizes pretending to be precision, no unlabelled buttons that force you to guess.

This is where honesty becomes UX. If the only video-with-sound option is 360p, the page says so instead of hiding it. People would rather see a small option than feel tricked into one.

What I stopped doing

I stopped putting feature lists above the tool. Nobody visits a downloader to read about the downloader; the three-step guide (copy link, paste, download) sits below the working tool, not above it. I stopped animating anything on the input. A tool page should feel instant and a little boring.

The boring is deliberate. On ramrom.io, the homepage is an input, a button, and then the explanation. Every extra pixel above that input is a pixel between a person and the thing they came for.

None of this is a framework or a design system. It is one PHP page and a bit of vanilla JavaScript, with the button in the one place thumbs already expect it. Small decisions, but on a tool site they are the whole product.