Five Things I Check Before Publishing a Small Tool
The checks that come before putting a small family tool on the web: scope, real records, privacy, readable pages, and honest follow-through.
Written from Ted TH Lee's own build records.
When I build a small tool, it is tempting to stop at 'it works.' If it removes one irritation at home and has been used a few times, that already feels like success. A public website invites the next questions, though: who can use this today, can the claims on the page be checked, and where should a first-time visitor go next? These are the five checks I use when deciding what to publish from this lab.
1. Say whether the tool is actually open
Not every project is in the same state. The math and science maps and How to Claude can be opened now; other tools are used only within the family or are still being considered for release. Presenting the latter as a live product would lead a visitor to something they cannot use. Each app page therefore identifies whether it is public, family-only, or still under consideration, and explains the reason when it can.
2. Keep the context, not only the feature list
A list saying that an app uses OCR or saves progress does not explain why it exists. The starting point matters: moving academy homework into reminders, delaying vocabulary study because copying words took too long, or finding a missing math concept while studying with a child. App pages describe the use flow; build notes describe the decisions made while building it. They answer different questions instead of repeating the same copy.
3. Put the privacy boundary before convenience
Tools for children and family life can easily accumulate records. The public hub and course can be read without a login, while a service that continues learning progress may need an account and storage. The privacy policy separates those cases rather than blurring them into one statement. Being careful about opening an unfinished family tool follows the same boundary.
4. Let search engines see a page that people can read
If a page only becomes complete inside a browser, a search engine or first-time visitor can meet an empty shell. The app pages and build notes here are also produced as static HTML with a title, description, and body. Korean and English pages point to their correct counterparts, and each page uses one final representative URL. This does not promise a ranking; it is simply the groundwork for a real page and tool to be found.
5. Publishing starts the next round of checking
A small tool can be improved quickly when its users are close by, but a public reader arrives without that context. When I revise a page, I look first for a newly verified fact or a decision changed by real use, not a way to inflate a word count. Limits stay in the current-status section, and questions or corrections have a contact route. For a household solution to be useful to someone else, it is better to keep saying what has been checked and what remains.