What building and burying things taught me

A running list. No project names, because the lessons outlived the projects. Most of it I learned the expensive way.

1. Most of my best ideas are wrong, and that's the job. The point isn't to be right more often. It's to find out you're wrong before it costs a season of your life.
2. Not every pain point is worth scratching. A real annoyance isn't automatically a product. Some pains are too small to pay for, too rare to matter, or ones people have quietly made peace with. "This bugs me" is where you start looking, not where you start building.
3. Kill it on paper before you kill it in code. Half my dead projects could have died in an afternoon of honest questions instead of two months of building. The honest questions are the cheap part. I keep skipping them anyway.
4. Talk to the person who'd pay before you build, not after. It's slow and uncomfortable and it saves months. I skip it constantly and pay for it every time.
5. "I'd use that" is not "I'd pay for that." People are generous with encouragement and stingy with money. Only the second one keeps the lights on.
6. If you can't say why someone would pay in one sentence, they won't. When the answer needs a paragraph, the value isn't unclear to them. It's unclear to me.
7. Build for someone who'll pay, not a comfortable middle. The serious users already have tools. The casual ones love it and never open their wallet. The space between them feels huge until you try to charge for it.
8. A demo lies; the second session tells the truth. Anyone will try a thing once. The real question is whether they come back on day two without you nudging them.
9. Ship the ugly, simple version first. Every time I polished an idea before anyone touched it, I buried the part that actually worked under features nobody asked for. The plain version usually wins.
10. Polish nothing until someone wants the rough version. I've spent days perfecting screens for an app that never had a reason to exist. Earn the right to polish.
11. Scope is a promise you make to your future self at 11pm. Every "while I'm at it" feature is a debt that comes due when you're tired and just want to release.
12. The build was never the hard part. Getting it working is the fun part. The boring last mile, the signing, the store review, the empty state, the refund flow, is where things quietly die on the shelf.
13. Finishing is a different skill from starting, and I'm better at one of them. Starting is dopamine. Finishing is chores. The honest pile of half-built things is the receipt.
14. A tool that can't handle real data isn't a tool. It demos beautifully with five items and falls apart at five hundred. If the painful version of the user can't use it, nobody serious will.
15. The market doesn't care how hard it was to build. Months of clever engineering and a weekend hack get judged on the same thing: does it solve a problem someone feels today.
16. Distribution is the product. A great thing nobody can find loses to an okay thing on every shelf. Building it is maybe a third of the work.
17. Build-in-public is mostly builders talking to builders. Unless you're genuinely B2C, the launch platforms and the "building in public" threads feel like momentum and aren't. The people cheering you on are other makers, and they will almost never be your customer. Do it because it's fun, not because it's marketing.
18. Free users aren't customers; they're a cost. Worth having for reach and feedback, but a thousand people who'll never pay is a server bill, not a business.
19. Respect what people already paid for. Don't yank access the second someone cancels; they paid through the period. How you treat people on the way out is what they remember.
20. Never delete on an automated event. Mark a status. A webhook fires at 3am, removes the wrong thing, and you find out a week later when the numbers stop adding up. Reversible beats tidy.
21. Trace the actual flow; don't grep for smells. You can scan code for ugly patterns all day and still miss the freeze a real user hits on the very first tap. Walk the path they walk.
22. Let the model judge; let code keep the books. AI is great at reading messy intent and unreliable at arithmetic. Anything that has to be exact belongs in plain, boring code.
23. A vivid example in a prompt becomes a script. Give a model a concrete sample and it repeats it word for word at the worst moment. Describe the shape, not the line.
24. An input you don't control is a single point of death. If the whole product leans on someone else's API, their roadmap is your roadmap and their outage is your obituary.
25. AI gets you to "shipped." It doesn't make anyone want it. The least automatable part is still whether the thing should exist. That part stays yours.
26. The cost of being wrong dropped; the value of being right didn't. When failing costs a weekend instead of a year, you can afford a lot more shots at the rare one that lands. So I keep taking them.