---
name: free_tool_marketing
description: "Build a small free tool as a marketing channel for a paid product: score tool ideas on product fit and discovery, cut scope so v1 ships in days, design the result page and the path into the paid product, and launch and measure with tagged links and funnel events. Use when planning a free calculator, grader, generator, checker or widget to attract buyers, deciding whether a free tool is worth building, or reviewing a free tool that gets traffic but no signups."
---

# Free Tool Marketing

## Purpose

A free tool earns its keep when the person using it is the buyer, the problem it solves sits right next to the paid product, and the result points to a clear next step. That pattern has a name in the growth literature: engineering as marketing, one of the traction channels in Traction by Gabriel Weinberg and Justin Mares. HubSpot Website Grader is the case most people cite. HubSpot says it built the grader to generate buzz, traffic, links, and leads for its software, and later reported grading millions of sites.

Most free tools fail in predictable ways. The idea chases search volume for a problem the buyer does not have. Scope grows until the tool is a second product. The tool works fine and then asks for an email before showing any result, so nobody finishes it. Or it launches with no tags and no events, so six months later nobody can say whether it drove a single signup. This skill covers idea scoring, scope rules, page and result design, launch, and the keep or kill review.

## Workflow

1. **Start from buyer problems, not tool formats.** List problems from support tickets, sales calls, onboarding drop off, and the questions buyers ask in the week before they buy. Write each candidate as a job in one line: who has it, how often, and what a good answer looks like. A calculator, grader, generator, checker, and template are formats. Pick the format after the job is clear.

2. **Name the paid connection for every candidate.** For each idea, write where it sits against the paid product: a step before the paid job (assess, estimate, plan), a small slice of the paid job done once for free, or a step after it (report, share, check the result). If you cannot write that line without stretching, the idea is a traffic play for the wrong audience. Drop it now, before scoring flatters it.

3. **Score every candidate with the bundled scorer.** Fill in `assets/sample-ideas.json` in your own file using the eight 1 to 5 scores plus build_days and maintenance_hours_per_month, then run it:
```sh
python3 scripts/score_ideas.py ideas.json
```
Weights put product fit first (25) and search evidence second (20), then pain frequency, shareability, conversion path, uniqueness, and ease of build and upkeep. Score search evidence from evidence you actually have: query data, ticket counts, call notes. A hunch gets a 2, not a 4. The scorer applies hard gates on top of the total: product fit under 3 kills the idea no matter how big the search demand is, a build over 20 days kills it as a second product, and no discovery route (weak search evidence and weak shareability) kills it too. Worked scoring for an invoicing product is in `references/worked-example.md`.

4. **Pick one tool and write the kill list.** Build the top BUILD idea only. Write two lists before any code: what v1 does, in at most five bullets, and what v1 cuts on purpose, naming the tempting extras: accounts, saved history, PDF export, extra currencies or rule sets, embeds, a directory of sibling tools. Post the cut list where the team can see it. Scope questions during the build get answered from the cut list, not relitigated.

5. **Hold the build to days, not months.** V1 rules: one page, one job, at most five input fields, one result screen, no account required, no backend unless the calculation truly needs private data or a live external check. Reuse the paid product stack, components, and hosting so the tool inherits fixes instead of becoming a separate site to patch. If the honest estimate passes 10 build days, go back to step 4 and cut until it does not. A tool that ships in 3 days and gets real use teaches more than a tool that ships in 6 weeks to silence.

6. **Give the result before any ask.** The user gets a full, usable result free: the number, the grade, the generated text, with the working shown where the result needs trust. Email comes after the result and only for a reason tied to the result: send it, save it, expand it into a full report. Gating the result itself trades away completion, sharing, and search value for a list of annoyed addresses. Test the tool as a stranger would: no login, no instructions doc, result in under a minute.

7. **Design the result page as the conversion page.** The result screen carries the one next step, written for this result: save this calculation as a live invoice, run this check on a schedule, turn this draft into the real thing in the product. Carry the user input into signup where you can, so the first product screen already holds their numbers. One next step, specific, honest about what the paid product adds. No popups over the result, no countdown tricks, no fake limits.

8. **Build the search and share surfaces into the page.** One indexable page per tool, with a descriptive title and heading in the words a searcher types, crawlable links from related product and help pages, and a short method section under the tool that answers the questions around the job and makes the method citable. Add Open Graph tags (og:title, og:type, og:image, og:url, og:description) so a shared link shows a deliberate preview. Make the output itself shareable where privacy allows: a result link, an export, or an image of the output. Search and sharing are the two compounding channels a tool has. A tool hidden behind a script only page or a login gives both of them away.

9. **Instrument before launch, not after.** Wire the funnel events from `references/launch-and-measurement.md`: tool_view, tool_start, tool_complete, result_share, product_click, signup, and activated, each with the tool name attached. Tag every launch link with utm_source, utm_medium, and utm_campaign as a fixed set, lowercase, following the pattern in that reference. Google Analytics Help is clear that those three belong together on campaign links, with utm_term and utm_content optional. Click your own tagged links in a test session and confirm the events and tags land where the report will read them.

10. **Launch in waves to places the tool is a real answer.** Follow the sequence in `references/launch-and-measurement.md`: owned users and list first, then the communities and directories where this problem is discussed, then partner and writer outreach with the tool as a resource. Read each venue current rules before posting and obey them: several launch venues forbid asking for upvotes, and the safe ask everywhere is to try the tool and comment with a result or a case. Log each placement and its tagged link as you post. Staff launch day to reply and to fix what the first wave breaks.

11. **Run the keep, fix, or kill review on the date you set at launch.** At 30 days for a small tool, 90 for a search led one, judge use, fit, conversion, and upkeep cost as laid out in the reference. Compare tool signups activation against signups from other channels, not against page views. Decide in the meeting: invest, fix one named funnel leak and re-review once, or fold the tool into the product or a help page and redirect the URL. Write the decision and the numbers behind it down either way, so the next tool idea starts from evidence.

## Output Contract

- An idea sheet: the candidate jobs with their paid connection lines, scored with `scripts/score_ideas.py`, showing the weighted score, the verdict (BUILD, CUT_SCOPE, PARK, or KILL), and the gate reasons for every idea not built.
- A v1 scope doc for the chosen tool: at most five in scope bullets, the explicit cut list, the build day estimate, and the maintenance owner.
- A page plan: target search phrase, input fields (five or fewer), the result shown free, the single next step into the paid product and what input carries over, the share mechanism, and the Open Graph and method section plan.
- A launch doc: placements in wave order with a tagged link for each, the funnel events confirmed in testing, and the review date with keep, fix, and kill thresholds written in advance.
- A review note at the review date: completions, product clicks, signups, activation against other channels, upkeep hours, and the decision taken with its reason.

## Operating Rules

1. Product fit beats search demand, every time. A popular tool for non buyers is a cost center with good traffic charts.
2. The result is free and comes first. Gate the delivery, the save, or the deep report if you gate anything. Never gate the answer itself.
3. One tool, one job, one page. A tool that does three jobs ranks for none, explains badly, and never ships.
4. Scope is a marketing decision, not an engineering failure. Cutting v1 to days is how the channel stays cheap enough to test again.
5. Never invent demand or results. Score search evidence from data you hold, report launch results from your own events, and label any example numbers as examples. Vendor claims about free tools in general are not evidence for your tool.
6. No dark patterns: no fake scarcity, no pre checked marketing consent, no email required to see a result you promised free, no share prompt before the user has a result.
7. Respect the data the tool touches. If users enter client names, financial figures, health details, or other sensitive data, say what is stored, store the minimum, never put sensitive values in URLs or share links, and check the privacy duties that apply before launch.
8. The tool is a product surface. It gets accessibility basics (labels on every field, keyboard use, readable contrast), error states that name the bad input, and a maintenance owner. A broken free tool argues against the paid product better than any competitor can.
9. Venue rules outrank launch tactics. When a community or launch site forbids a move, the move is off the plan, even on launch day, even if a competitor did it.
10. A dead tool gets folded in or redirected, not left to rot. The review decision is part of the work, and skipping it turns one test into permanent upkeep.