the first product i built that someone paid for, and what it taught me about building

product · 2024-10-18 · 6 min

the first product i built that someone paid for was not the one i planned to ship. the one i planned was a dashboard for freelancers: projects, invoices, time tracking, a client portal. i spent six months on it. nobody paid.

the one that sold was a small windows utility that cleaned temporary files and startup entries. it was ugly, it was narrow, and it made nine dollars. forty people bought it in the first month. that was enough to teach me more than the dashboard ever did.

the dashboard problem

the dashboard was a better product in every way i could measure. it had more features, a nicer interface, and a clearer story. it also required the buyer to change how they worked. a freelancer with a working spreadsheet does not wake up wanting a new system. they wake up wanting the invoice to be done. my dashboard asked them to move their whole workflow before they got the first useful minute.

that is the trap. a product can be good and still be a bad first purchase, because the cost of adopting it is higher than the cost of the problem it solves. i was selling a new habit, not a tool.

the cleaner problem

the cleaner did one thing: it found the files windows had left behind and removed them. the result was visible in thirty seconds. free space before, free space after. no onboarding, no import, no new workflow. the user did not have to trust me. they could see it.

that visibility is the whole product. the utility did not need a landing page with a manifesto. it needed a screenshot of a number going up.

what the sale taught me

sell the job, not the platform. "clean up the mess windows made" is a job. "manage your freelance business" is a platform. the first one is a purchase. the second one is a project.

make the result visible before the commitment. a free scan, a before-and-after, a sample. the buyer should be able to see the value before they decide to believe the claim. if the value only appears after setup, most buyers never get there.

price below the approval threshold. nine dollars is an impulse. nine hundred dollars is a meeting. the first product should be easy to say yes to, because the first sale is not really about revenue. it is about proof that someone will pay.

support is part of the product. the first week was not code. it was email: how do i uninstall it, why did it flag this file, can i use it on my work laptop. the product was the software plus the answers. a product that ships without the answers is a beta with a price tag.

distribution is a feature. i posted the cleaner where people were already complaining about slow laptops. the dashboard had no such place. it was a solution looking for a room. the cleaner had a room and walked into it.

what i would do differently

i would ship the small thing first. not because small is noble, but because small is testable. the cleaner could be built in two weeks and tested in a month. the dashboard needed six months before the first honest signal, and six months is a long time to be wrong.

i would also charge sooner. i gave the cleaner a free tier for two weeks, and the free tier taught me nothing i could not have learned from ten paid users. a price is a question. a free download is a shrug.

the thing that stuck

the thing that stuck is not "build small". it is "build the thing whose value is visible before the buyer has to change". that rule applies to websites too. a landing page that shows the result is easier to buy than a page that explains the process. a service page with a price range is easier to trust than one that says "contact us for a quote". the same lesson, different surface.

i still have the cleaner's sales page somewhere. it is not a good page. it worked because the product was easy to understand, and the page did not get in the way.

for the website version of the same idea, see what makes a website look trustworthy. for the pricing side, see why cheap websites cost more.