What building 98 free browser tools and 32 games taught me about distribution: search intent magnets, zero marginal cost, and the power law nobody mentions.
Distribution is the part nobody hands you. You can build something genuinely good in a month and then spend two years discovering that nobody will ever type its name into a search box — because they don't know the name, and they were never looking for a product in the first place. They were looking to solve one specific annoyance in the next ninety seconds.
Over the past year my portfolio turned into 98 free browser tools and 32 browser games. All client-side, no accounts, no server, hosted on Firebase for exactly $0 a month. That was not a plan I wrote down on day one — it started as three utilities I needed myself. But somewhere around tool number thirty the traffic changed shape, and I started paying attention to why.
The thesis I ended up with: a free tool is a search-intent magnet, and unlike almost every other marketing asset, it compounds. Each one targets a specific long-tail query someone types with a job to be done right now, and it delivers the value before asking for anything at all. This post is what I actually learned — why one utility beats a landing page, the compounding math of many small surfaces, running everything client-side so scale never sends you a bill, the two distribution details that mattered most, the honest downsides nobody puts in the growth thread, and the strategic point at the end: what you're really buying, which is not revenue.
A landing page is a promise. A tool is a demonstration. That difference is the whole argument.
Start with intent. Nobody searches for a description of your product unless they already know it exists, which means a landing page competes for the words you use about yourself. A tool competes for the words the user uses about their problem. "Convert webp to png." "Cron expression meaning." "Contrast checker WCAG AA." Those are queries typed by a person with a task open in another tab, and the person typing them is not in a research mood — they want the answer in one click and then they want to leave.
That is exactly what makes a tool the better first contact. It is useful before signup, which is a much rarer property than it sounds. Every conversion-optimised instinct says put an email gate in front of the value, and for a four-second job that instinct is fatal: gate a webp converter and the visitor hits back and takes the third result instead. The tool's job is not to convert. Its job is to work, be remembered, and get linked to.
It also requires no trust. This is the underrated part. A stranger arriving from a search result knows nothing about me, and I'm asking them for nothing — no account, no card, and because everything runs in the browser, not even their file. "Your data never leaves this tab" is a real technical property here, not a privacy-policy sentence, and it removes the last hesitation before someone drops a document into a box on a site they've never heard of.
And the shapes of the two assets over time are opposite. A landing page peaks the week you launch it and decays from there; you have to keep spending to point traffic at it. A tool starts near zero and climbs, because rankings accumulate and links accumulate. One is a firework. The other is a tree.
Here's the arithmetic that convinced me to keep going past the first handful.
One page targeting one head term is a fight against every well-funded competitor in your category, and you will probably lose it. But 130 pages, each ranking for three to eight long-tail phrases, is somewhere between four hundred and a thousand distinct entry points. None of those individual fights are hard, because most long-tail queries are contested by almost nobody.
The per-unit numbers look pathetic in isolation and that's the trap. A tool pulling 40 visits a month is a rounding error — not worth an afternoon. Ninety-eight of them at that average is 4,000 visits a month, and crucially that number doesn't fall when I stop working on it. It's not paid traffic and it isn't a launch spike. It's an installed base.
Three properties make the portfolio genuinely better than one big surface, rather than just bigger:
The catch is patience. This is a six-to-nine month feedback loop, not a two-week one. Nothing I shipped told me anything useful about itself inside the first quarter, and judging a tool early is how you kill the ones that would have worked.
Every tool and every game on the site runs entirely in the browser. No API keys, no server-side processing, no per-request cost, no queue. Files are read with the File API, processed in memory, and handed back — they never touch a network. The site is static assets on Firebase Hosting, and my project is on the Blaze plan for unrelated reasons while the actual bill is $0 a month, because there are no Cloud Functions, no Storage reads, and no database in the request path. App binaries live on GitHub Releases rather than in Storage for the same reason.
This is a strategic choice, not a technical convenience, and it has three consequences.
Success can't hurt you. The genuinely scary thing about a server-side free tool is it going viral. Client-side, a front-page day costs me the same as a dead Tuesday: nothing. There is no capacity to plan, no bill to fear, and no reason to ever put a rate limit in front of a stranger.
Nothing has to be shut down. A server-side tool has an operational cost floor, so eventually there's a quarter where you kill it. Static files have no floor. A tool I wrote fourteen months ago and haven't opened since still works, still ranks, and still costs zero. In a strategy built on compounding, the ability to never prune is worth more than it sounds.
The privacy story is free and true. "Runs entirely in your browser" is both the cheapest infrastructure and the strongest trust claim, and I didn't have to choose between them.
The obvious failure mode of one app containing 130 tools is that everybody downloads all of it. That is exactly what happened to me first.
The fix was code splitting — deferred imports, so each tool and each game compiles into its own chunk that loads only when its route is hit. Combined with self-hosting the fonts instead of paying a round-trip to a font CDN, and removing a per-frame backdrop blur on the nav that was eating frames on mid-range Android, the initial payload went from 1.92MB to 1.08MB brotli.
Speed matters twice here, and the second reason is the one people forget. It's a ranking input, yes. But more importantly, someone who arrived to do a four-second job will not wait four seconds for the page. Every hundred milliseconds of load time is a fraction of the visitors you already earned, walking away before they see the thing you built for them.
A tool gets pasted into a Slack thread, a group chat, a Discord. That moment is the highest-intent distribution you will ever get for free: a real person is recommending you to a colleague who has the exact problem right now.
For a long time I threw that moment away. Without per-page Open Graph tags, the unfurl was a bare URL or, at best, the site favicon and a generic site description repeated on all 130 pages. A grey box in a Slack thread converts far worse than a card that says what the tool is.
So every tool and game now has a branded share card generated at build time: one 1200×630 template, the tool's name, its category, and the wordmark, rendered by a script rather than assembled by hand — 130 images nobody had to design individually. Along with it, twitter:card set to summary_large_image, and a per-page <title> and description written around the query rather than around the brand.
<meta property="og:title" content="WebP to PNG Converter — devShakib Tools"><meta property="og:image" content="https://…/og/webp-to-png.png"><meta name="twitter:card" content="summary_large_image">
The <title> point is worth its own sentence, because it's the most common own-goal I see on tool sites. Leading with your brand — "devShakib | WebP Converter" — spends the most valuable characters in the search result on words the searcher has never heard of. Lead with what they typed. Your name goes at the end, where it still gets seen and still builds recognition without costing you the click.
The second detail that paid for itself: every tool page ends with a short block of four to six genuinely related tools, plus a link up to its category hub.
This does two jobs. It moves authority from the pages that rank to the pages that don't, which is the only lever you have for a brand-new page on an established domain. And it converts a one-job visitor into a two-job visitor — which is the only "conversion" that matters at this stage, because the second tool is the moment someone stops seeing a random search result and starts seeing a place.
I got this wrong at first in the obvious way: a mega-footer linking all 98 tools from every page. That does nothing. It dilutes each link to noise, it looks like every low-effort SEO farm ever built, and no human has ever read a footer with 98 links in it. A curated handful of actually-related tools outperforms an exhaustive index, both for the algorithm and for the person.
The related block is generated from the same category and tag metadata that builds the sitemap, so adding a tool wires it into the graph automatically. If that step is manual, it stops happening around tool forty.
Growth threads about this strategy stop here, at the part where it sounds like free money. It isn't, and there are two costs that are much larger than anyone tells you.
Traffic across a portfolio of tools is not evenly distributed and it is not close. In my case roughly six or seven tools produce the large majority of everything, and the median tool gets a genuinely trivial amount — a few dozen visits a month, sometimes fewer. Half of what I built is, in traffic terms, decoration.
You cannot know in advance which ones. My predictions were not slightly wrong, they were uncorrelated. The engineering I'm proudest of is on tools nobody visits, and one of the winners is a fifty-line utility I built in an evening to scratch my own itch.
That has a hard implication: this strategy only works if each unit is genuinely cheap. If a tool costs three weeks, building ninety of them to find seven is a catastrophe. If it costs a day or two on top of a shared design system and shared components, the ninety that miss are simply the price of discovering the seven that don't. Anything that raises per-tool cost — bespoke design, a custom backend, a separate deployment — attacks the premise directly.
Hosting is free. Maintenance is not.
130 things that can break is 130 things that can break. A change to the shared design system touches every one of them. A dependency bump has to be regression-tested across the whole family. A browser API deprecation can quietly kill a tool you haven't opened in a year, and you will find out from a stranger's email, if at all. The QA sweep I ran across the games recently turned up twelve real correctness bugs — three high severity — in code that had been live and looked fine.
What keeps it survivable:
The last downside is the one that makes the "just ship 100 tiny tools" advice quietly wrong. A single-purpose tool that does exactly one thing gets the visit and loses the person. They do the job, close the tab, and never learn your name. You paid for the ranking and got nothing back.
Depth is what turns a visit into a memory. A colour picker that picks a colour is a twenty-second visit. One with palette generation, WCAG contrast checking, export to CSS variables, Tailwind config and a Flutter ColorScheme, plus a saved history of recent palettes — that's a tab someone keeps open, and it's the one they send to a colleague.
This is the same rule I apply to my Flutter tools family: a single-purpose MVP is not releasable. Modes, settings, history, charts, export. It's more work per unit, and it directly contradicts the cheapness argument above — which is the real tension in this strategy, and the honest answer is sequencing. Ship every new tool minimal but complete, then let the traffic tell you which five deserve depth. That feedback is the one genuine advantage of having many surfaces, and most people never use it.
Depth also buys you more long tail, which is the part that surprised me. Every additional mode is a new query the page can rank for. "Hex to Flutter Color" is a query I can win outright; "colour picker" is a war I have no business entering.
Be clear-eyed about this, because it's where the strategy is most often oversold.
It does not make money. Free, client-side tools with no accounts have no revenue mechanism, and the obvious ways to bolt one on — ads, an email wall, a "pro" tier on a four-second utility — destroy the exact properties that made them work: fast, clean, no trust required. I've decided not to, and that decision means the traffic is not income and never will be.
What it buys is two things, and you should know which one you're paying for.
The first is an audience: a genuine top of funnel, a stream of people who arrive with a problem you can solve. But be honest about the overlap. An audience that came for a JSON formatter is not automatically an audience for your B2B product, and assuming the transfer is how people end up with big numbers and no business. Check it before you build a strategy on it.
The second is a credibility artifact, and for me this has been the higher-value of the two by a distance. A body of shipped, public, working software is a claim nobody can argue with. As a CTO hiring, as an engineer being evaluated, as someone pitching work — "here are 130 things I built that work, go click any of them" is worth more than a paragraph of adjectives on a CV. It has opened conversations that no amount of describing myself ever did.
So pick deliberately. If you need revenue in six months, this is the wrong strategy: it is slow, indirect, and the payoff isn't cash. If you need to be findable and credible in eighteen months, it's one of the highest-leverage things a technical founder can do, because it is built entirely out of the thing you're already good at — shipping software — rather than out of a skill you'd have to buy.
The failure mode to avoid is treating tools as a substitute for a business model, telling yourself the traffic will convert later. It won't, on its own. Traffic is not a business model. It's a precondition for one, and preconditions are worth building — as long as you know that's what you're building.
Free tools are the rare growth channel a technical founder can build out of pure engineering, and that's exactly why it's tempting to oversell them. What I have after a year is not revenue. It's a set of small, permanent surfaces that keep bringing strangers to my name while I'm asleep, and a portfolio I can point at instead of describing. Build them cheap, give the winners depth, and be honest with yourself about which of the two you're buying.