A Pre-Launch Checklist for a Small Web Tool

September 24, 2026

Before you publish a small web tool, check seven things: that it works, that it looks right on a phone, that it loads quickly, that people can use it with a keyboard and screen reader, that it handles personal data responsibly, that no secrets are exposed, and that you have a backup. Most of these checks take a few minutes each, and they catch the problems visitors would otherwise find for you.

Work through the list in order, and fix problems as you go.

1. Function

Run your test list. This should include normal cases, edge cases and a reload:

• Inputs where you know the correct output.
• Empty, zero, negative and very large values.
• Invalid input, such as letters in a number field.
• Every button and link.
• Reloading the page, especially if the tool saves data.

If your tool never had a written test list, make one now from what the tool is supposed to do. Five to ten items are enough. Include a test for each feature you added through the assistant, because additions are the most likely source of hidden breakage.

2. Phone and screen sizes

Many visitors will arrive on a phone. Check the tool on a real phone if you can, and otherwise use the device preview in your browser’s developer tools. Look for:

1. Text that runs off the screen or is too small to read.
2. Buttons too small to tap without hitting the wrong one.
3. Horizontal scrolling that should not exist.
4. Overlapping elements.
5. Behavior when the phone is turned sideways.

Also try a very wide screen and a narrow window on a computer. If a layout problem shows up, describe the size and the symptom to the assistant when you ask for a fix.

3. Speed

A small tool should load almost instantly. If it does not, find out why. Common causes are large images, unnecessary libraries and fonts loaded from several sources. Check the size of your files. Photos straight from a camera can be several megabytes and are easy to shrink.

Test with a throttled connection in developer tools to see what slow-network visitors experience. If the page shows a blank screen for several seconds, consider ways to simplify it.

4. Accessibility

Some visitors use keyboards, screen readers or larger text. A few quick checks make a big difference:

• Can you reach every control using the Tab key, and can you see which one is focused?
• Do images have descriptive alt text?
• Is text contrast strong enough to read in bright light?
• Are form fields labeled?
• Does the page still work when you zoom to 200 percent?

Your AI assistant can review the code for these issues if you ask, though you should still test by hand.

5. Privacy and personal data

Ask what your tool collects. If the answer is nothing, say so on the page. If it stores data in the browser, explain that in plain language. If it sends data anywhere, including to analytics or form services, tell visitors what is sent and why.

Rules about personal data differ by place, and a general guide cannot cover them. If you collect names, emails or other personal details, read official guidance for your location or consult a professional.

6. Security and secrets

Search your files for keys, tokens and passwords. Remove anything that should not be public, as everything you upload is visible. Check that external scripts come from sources you trust, and that your pages load over HTTPS. If you use any API key, confirm it sits on a server and not in browser code. See our guide on keeping API keys secret.

7. Backup and records

Keep a copy of the final folder on your computer and, ideally, in a second place. Write in your notes file:

• The date you published and the host.
• The address of the site.
• Where the domain is registered and when it renews, if you have one.
• Which version of the files is live.

Without these notes, you will spend time reconstructing them when something breaks.

After you publish

Open the live address on your phone and run a short version of the test list again. Differences between your local copy and the hosted version are not unusual: a missing file, a changed path or a cached page. Ask a friend to try the tool without instructions, and watch where they hesitate.

Add a page title and a description

Small touches make a tool feel finished. Give the page a clear title, since it appears in the browser tab and in search results. Add a short description in the page’s head section, so link previews and search engines have something sensible to show. Check that the tab displays a small icon if you want one, and that sharing the link in a message produces a readable preview.

These details are easy to forget because they do not change how the tool works. They change how it looks when someone first meets it, which is often when they decide whether to trust it. Ask your assistant to add them, then check the result by sending the link to yourself.

Treat the checklist as a living document. Each time a real problem slips through, add a line that would have caught it. Over several projects, the list becomes tailored to the mistakes you actually make, such as forgetting alt text or leaving a test file in the upload folder. Keep it in the same notes file as your project log, so it is at hand on launch day, when it is tempting to skip steps because the tool already seems fine.

Next steps

Copy this list into your notes file and adjust it to your tool. Run it on the next project you plan to publish and mark each item. When you find a problem, add a specific check for it so the list grows with your experience.