Some of the best product signals do not arrive as a survey response or a polished waitlist.
Sometimes they show up quietly: a small tool keeps getting used long after its maker has stopped thinking about it.
That is what happened to a free truss-analysis tool built by developer Andrew Young. He made it for a real engineering task, put it online, and moved on. Years later, Google Search Console emails showed that the tool was attracting thousands of clicks. By the time he looked closely, he said it had collected more than 28,000 email addresses and was serving a much larger audience than several projects he had actively tried to grow.
The eventual paid version reportedly reached $500 in monthly recurring revenue within three months. That number is useful context, but it is not the main lesson.
The interesting part is the sequence: solve one narrow job well, let real use reveal the demand, and charge only when a group of users needs more than the free tool can reasonably provide.
The case: a side project that did not behave like a side project
The tool helped users analyse trusses, the triangular structures used in roofs and other buildings. It was not built around a broad idea such as “AI for construction.” It did one technical job that people repeatedly needed done.
According to the founder’s account, three things helped it grow:
- The search query described a clear task: people were actively looking for a free way to analyse a truss.
- Existing options were weak, awkward, or hard to trust.
- The tool showed its calculation report instead of returning an unexplained answer.
That last point matters. In a technical or high-stakes task, a result without an explanation is often less useful than no result at all. The report helped users check the work and made the tool feel less like a black box.
This is a better opportunity pattern than “build a tool in a growing market.” Look for a repeated task where users already know what they want to do, but dislike the current way of doing it.
Lesson 1: Start with a job people can describe in a search box
The strongest early tool ideas usually sound unglamorous. They are specific actions, not vague ambitions.
Good examples look like this:
- Calculate X from Y
- Convert this file into that format
- Check whether this configuration will work
- Generate a report from a repetitive input
- Compare two options using a rule people do not want to calculate by hand
These searches are valuable because the user has already reached the action stage. They are not browsing for inspiration. They want an answer, a file, a calculation, or a next step.
Before building anything, search the exact task phrase and inspect the first page of results. You are looking for gaps such as old-looking tools that are difficult on mobile, pages with ads but little help, results with no explanation of how an answer was produced, or paid software that is too heavy for a one-time job.
Do not treat a high search volume as proof by itself. A small but recurring problem can be much more useful if the existing results are poor and the audience has a reason to return.
Lesson 2: Make the free version complete enough to earn trust
The founder did not begin with a complicated product funnel. The core calculation was available for free, and users could get a useful result before being asked for anything.
That is especially important for a new tool. A visitor who has never heard of you is unlikely to create an account for a promise. They are more likely to trust a product after it solves a small part of their problem.
For a utility tool, the free experience should complete the basic job. The paid tier should support the next, more serious job.
| Free tool should help with | Paid version can help with |
|---|---|
| One simple calculation or conversion | Batch work, saved projects, exports, or collaboration |
| A first result | More scenarios, history, or advanced controls |
| A quick check | A report needed for work, clients, or repeat decisions |
This is not an argument for giving away every feature forever. It is a way to avoid charging before a user has seen evidence that the tool works.
Lesson 3: Ask for contact details after value, not before it
In the case study, the tool requested an email only after a user had run several analyses. That timing is much more thoughtful than placing a sign-up wall before the first result.
The principle is simple: collect a contact detail when the user has a reason to come back or save their work.
- Saving a previous result
- Exporting a report
- Comparing several versions of an answer
- Sending the result to a colleague
- Returning after a few successful uses
The email list was not valuable merely because it was large. It became useful because some subscribers had demonstrated repeat intent. That is a very different signal from a generic newsletter sign-up.
If you build a tool, record a few privacy-respecting product signals as well: how often a task is run, whether the same person returns, which advanced action they attempt, and which type of user benefits most. These signals help you decide what is worth charging for later.
Lesson 4: Monetize the repeat user, not the curious visitor
The founder’s paid version added features such as multiple load cases and more advanced design work. He also placed upgrade prompts at moments when a user needed those capabilities.
That is a more useful pricing question than “What should my monthly price be?”
Which user has already received enough value that the next limitation costs them time, money, or confidence?
For the truss tool, a student doing one calculation and a professional working through several cases were not the same customer. The free tool could serve the first user well. The second user had a stronger reason to pay.
Many early tools fail because their makers try to convert everyone. A better approach is to identify the smaller group with repeated, higher-value work.
What not to copy from this story
This case is useful, but it is not a template for every niche.
First, the reported 28,000-email result took years. It was not a fast launch trick. Search traffic compounds slowly, and a new tool may not receive meaningful data for a while.
Second, the topic involved calculations that can affect real-world decisions. If you build anything related to health, finance, engineering, or compliance, accuracy, clear limits, and expert review matter more than growth tactics.
Third, not every free user should become a customer. The founder noted that some users were unlikely to pay because they used the tool for school or a one-time task. That is normal. Your aim is not to force conversion. It is to make the paid offer valuable for the users who actually need it.
Finally, do not copy metrics you cannot verify. The traffic, email, and revenue figures in this article come from the founder’s public account. Use them as a case-study input, not as a promise.
A 7-day test for a free-tool opportunity
You do not need to build a full SaaS to test this idea.
| Day | Action | What you want to learn |
|---|---|---|
| 1 | List ten narrow tasks people may search for. | Is the task clear enough to describe in one sentence? |
| 2 | Review search results, tool reviews, and forum questions. | Are existing answers weak, outdated, or hard to trust? |
| 3 | Pick one task with a visible gap. Define the smallest useful output. | Can a visitor get a real result in under two minutes? |
| 4–5 | Build a simple prototype or manual version of the workflow. | Does it solve the task without unnecessary features? |
| 6 | Show it to a few people who have the problem. | What do they try to do after the first result? |
| 7 | Write down repeated requests and possible paid actions. | Is there a repeat-use or professional-use layer worth exploring? |
If the task does not require interaction, start with a useful content page before building a tool. But if the value lies in a calculation, conversion, comparison, or report, a focused free utility can be a stronger test than another generic landing page.
The real opportunity is hidden in repeat use
The free tool did not become interesting because it had impressive features. It became interesting because people kept returning to it.
That is the signal worth looking for: not “Would people say they want this?” but “Do people repeatedly use the simplest version when it is available?”
Build for one clear job. Make the first result useful. Watch what repeat users ask for. Then turn the next meaningful step into a product.
Case source: Andrew Young, “Converting a forgotten free tool into $500 MRR after 3 months” on Indie Hackers. Reported metrics and product details in this article are attributed to the founder’s account.