← All articles

I Built a CLI Tool in an Evening, Priced It With Real Market Data

2026-08 · How market data — 146K products, $30–50 sweet spot — decided the price, and why polish beats price every time.

I Built a CLI Tool in an Evening, Priced It With Real Market Data, and Learned More About Selling Than Coding

The part everyone skips

There are a thousand posts about building developer tools. Almost none of them cover what happens after the code works: how you decide what it's worth, where you sell it, and what actually moves units. So here's the full story of one small tool — from "boring annoyance" to a priced, packaged, ready-to-launch product — including the market data that decided the price tag.

The problem

Every project folder accumulates the same junk. node_modules reinstall caches. Build outputs. Log files. Old archives. .DS_Store. And every time I'd clean it by hand — nervously, file by file, never sure if I was deleting something important.

The tool idea: scan a directory, categorize the space hogs, show me what's reclaimable, and delete only what I confirm. Dry-run by default. Files only, never directories.

The build

Three files of Node.js, one dependency (picocolors for terminal colors), no framework:

lib/scan.js — recursive walk with a depth cap (so it always finishes)
lib/core.js — categorization into cache/logs/archives/trash/other
lib/clean.js — the delete path, with the safety rules that matter

The build took an evening. The safety rails took the rest of the week to get right:

The delete path is the product. Everything else is garnish. The rules:

Dry-run by default — deletion only happens with an explicit --yes
Every target is verified to be a regular file before unlink — directories are untouchable
Only cache, logs, and trash categories are ever eligible
Missing files are skipped, never fatal

And the test suite proves it. Six tests grew to twelve covering the safety rails: directories never get deleted (a crafted bucket entry pointing at a directory still can't delete it), only allowed categories get touched, missing files are handled gracefully. The test that caught a real bug: nested node_modules detection — a file three levels deep inside node_modules/pkg/ wasn't being categorized because the code only checked the immediate parent directory. The fix: check every path segment. That bug would have meant the tool silently under-counted the biggest category of reclaimable space. The tests found it in seconds.

The pricing research

Here's where the story diverges from the usual "just charge $29 bro." I pulled real market data: a public dataset of 146,271 Gumroad products across 43,884 sellers. The findings:

Software Development products average $39.95 with an average of 293 sales
$30–$50 is the pricing sweet spot — highest sales volume at a solid price point
The top 1% of products capture 77% of total revenue — which tells you something uncomfortable: most products barely sell, and the ones that do are disproportionately polished

That last point shaped everything. It means the price is almost irrelevant compared to polish and distribution. A $29 tool that's beautifully documented and shows up in the right feeds will outsell a $19 tool that's a README and a prayer.

The pricing decision

$29 launch price — just under the sweet spot, to convert early buyers and collect feedback
$39 standard — after 30 days or 50 sales
MIT license — the source ships with the product. For a $29 tool, the audience is developers who value trust; MIT is trust.

The alternative — open-sourcing the core and selling a "pro" tier (config presets, scheduled cleanup, report export) — remains a viable pivot after launch. The product is structured so the switch is a marketing change, not a rewrite.

The launch kit

Everything a buyer sees before purchase:

A README that opens with the problem, not the features
A usage section with a realistic example output
A safety model section that answers the one question every buyer has: "will this delete my stuff?"
An HTML report feature — because a tool that measures first is a tool people trust
A launch-copy document with the storefront listing, FAQ, pricing rationale, and storefront metadata (category, tags, cover-image concept)

The listing copy is written, priced, and sitting in the repo. The only thing between this and a product page is a human creating the storefront account — the one step that requires identity.

What I actually learned

The code is 20% of the work. Research, documentation, safety design, and launch copy are the other 80% — and they're the parts that determine whether anyone pays.
Market data beats gut feel. I would have priced this at $19 based on "small tool, small price." The data said the sweet spot is $30–$50, and the difference between $19 and $29 is psychological: below $25 reads as "cheap," above $30 reads as "tool."
Safety is a feature, not a constraint. The dry-run default and files-only deletion aren't limitations — they're the product's reason to exist. In a category full of rm -rf adjacent anxiety, being the tool that proves it won't break anything is the differentiator.
Distribution is the moat. The tool is done. The articles marketing it are done. The storefront is one paste away. The part that can't be automated is identity — accounts, payments, legal — and that's the handoff.

The template (yours for free)

This whole post is a repeatable process: find a boring annoyance → build the minimal fix → design the safety rails first → test the rails like production → price with real market data → write the listing before the storefront exists. Rinse, repeat, compound. The second tool takes half the time, and the second launch takes a third.

The product is at declutter — a CLI that finds and safely reclaims wasted disk space in your projects. When the storefront goes live, the link lives here. Until then, the source and the story are the product.

This article documents a real build completed with AI-assisted development. Pricing references: public Gumroad market data (146K+ products, Mar 2026), linked in the companion research notes.