Picking a stack to ship in a weekend, not debate for a week

Solo builders lose more weekends to stack debates than to actual bugs. I've done it myself on earlier abandoned projects — three days picking a framework, then nothing left in the tank to actually build the thing. For Rate My Username I set myself one rule before writing any code: every tool choice gets five minutes of thought, maximum, and the deciding question is "have I shipped something real with this before," not "is this the best possible option."

Boring on purpose

Nothing in the stack is unusual. That's deliberate. As a solo builder, every unfamiliar tool is a tax paid in debugging time later, usually at the worst possible moment — right after a feature ships and real users start hitting edge cases you didn't think to test. Boring, well-documented tools mean that when something breaks at 11pm, the fix is a quick search away instead of a dive into sparse docs or a dead GitHub issue thread.

Where I let myself spend the extra time

The one area I didn't rush was anything touching the result card, because that's the part of the product that actually gets seen by people who aren't me — it's what gets screenshotted and shared. Everything upstream of that (the form, the request handling, the storage) was built to be correct and forgettable. The rendering of the result card got the most iteration of anything in the entire build, because a product whose whole growth loop depends on a screenshot can't afford for that one screenshot to look anything less than intentional.

Shipping before it felt ready

The first live version of Rate My Username was missing things I now consider basic — no leaderboard, no battle mode, a scoring prompt that was noticeably rougher than it is now. I shipped it anyway, because the alternative was polishing in private for another few weeks with zero real usage data to tell me which of those planned features actually mattered. Every feature that exists now — the leaderboard, the battles, the bracket — got added after watching what people actually did with the tool, not from a roadmap I wrote before a single real user had touched it.

The takeaway I keep relearning

The stack was never the hard part. Deciding what not to build yet was. I'd rather ship a smaller, boring, reliable version of something and learn from real usage than spend that same time making technology choices nobody using the product will ever notice or care about.