Turn a vague “maybe I could build something online” thought into a small, testable utility idea — before you write a single line of code.
This workbook helps ordinary people discover, test and build tiny online tools that solve one useful problem. Before we tell someone what to build, we make them ask better questions.
A compact decision guide for turning a vague “maybe I could build something online” thought into a small, testable utility idea. It is designed for generators, calculators, estimators, QR or barcode tools, forms, checkers, converters, graphs, and other focused one-page utilities.
A promise that your idea will make money, a giant business-plan workbook, or permission to start coding because one answer sounded exciting. The job of these questions is to improve the idea before you spend heavily on it.
You are looking for clarity, usefulness, and testability — not certainty. Move slowly. Answer honestly. The best result of this workbook is a smaller, sharper idea than the one you started with.
Five sections. Twenty-five questions. One decision at the end. Treat this like a conversation with a patient friend, not a form to survive.
Start with a repeated human friction, not a tool format.
Trade “everyone” for a specific person you can picture.
Let the job — not the format — pick the shape of the tool.
Cut the idea down to a version one you could actually ship.
Turn confidence into evidence with the cheapest useful test.
Do not start with “I want to build a calculator.” Start with something a person repeatedly needs to calculate. The idea gets easier the moment the friction is real.
Look for ordinary friction: copying, estimating, rewriting, calculating, checking, formatting, comparing, scanning, collecting, or deciding.
Manual work is often a clue that a focused tool could save effort.
A rare problem can still be useful if the moment of need is intense.
Think wasted time, wrong totals, forgotten fields, inconsistent wording, bad formatting, or repeated checking.
If you need three paragraphs to explain the problem, it may still be too broad.
“Everyone” is not a useful first audience. A tiny tool becomes easier to shape when you can picture the person using it — their moment, their tab, their frustration.
Name a person or role, not a demographic cloud.
A generic budget calculator may be ordinary; an event budget calculator for volunteer organizers is clearer.
Search engines, Pinterest, forums, work templates, spreadsheets, videos, communities, or existing calculators can reveal behavior.
Clear labels, transparent calculations, useful examples, no unnecessary signup, and a result they understand can matter more than fancy design.
Repeat use is useful, but one-time urgent utilities can still be valuable. Know which kind you are designing.
Now choose the shape of the tool. The right format follows the job. Pick the verb first — generate, estimate, convert — and let the interface fall out of it.
Pick the verb that best describes what the user is trying to accomplish.
The output often reveals the right utility format.
Every extra field creates friction. Keep only what changes the result.
One immediately useful result is a stronger first version than five decorative outputs.
If yes, that is a strong sign you may have a genuinely tiny first version.
A useful idea can still be the wrong first project if version one is too heavy. This section trims the shape until you can actually ship it.
If users can get the core result without registering, keep registration out of version one.
Dashboards are often a second-product problem disguised as a first-version requirement.
Formula-based calculators, fixed transformations, forms, QR creation, and rule-based outputs are especially friendly starting points.
Cut until the tool still performs its one essential job.
A spreadsheet, form, manual service, mockup, no-code page, or simple script may be enough to learn whether the result matters.
A well-shaped idea is not automatically a wanted idea. This section turns confidence into evidence.
Define the signal before you test: clicks, replies, signups, repeated searches, waitlist joins, usage, or payment.
Look for people already trying to solve the task, not merely liking the idea of your solution.
Questions about current behavior usually reveal more than “Would you use my tool?”
A Pin, simple landing page, audience question, manual version, comparison post, waitlist, or clickable mockup can be enough for the next decision.
Think newsletter, relevant template, small digital product, affiliate resource, sponsorship, paid feature, lead, or advertising later — but usefulness comes first.
Take a breath. Skim your 25 answers and circle the two or three that feel most alive — the ones where the friction is specific and the person is real. Those are your shortlist.
Use this page only after you complete the 25 questions. Shortlist no more than three ideas. The goal is to choose the next test, not crown a forever business.
| # | Idea | Specific user | One useful job | Smallest version | Cheapest next test |
|---|---|---|---|---|---|
| 01 | |||||
| 02 | |||||
| 03 |
“Smallest version” means the least you could ship this week. “Cheapest next test” means the smallest experiment that would produce real evidence of demand — a Pin, a landing page, a spreadsheet, a manual service.
One idea. One test. One decision rule for continuing. This is the whole game — the goal is momentum, not certainty.
Once you have one idea worth examining, use the Tiny Tool Idea Scorecard to pressure-test it across ten dimensions.
The Scorecard walks you through problem clarity, user clarity, urgency, friction, tool fit, input simplicity, output value, build simplicity, evidence path, and value path — so you can see, in one page, which parts of your idea are already sharp and which parts still need work before you invest another hour.