Growth: What Code Nobody Used Taught Me

My most valuable coding habit has nothing to do with which framework I know well. It's a reflex drilled into me during my years at a brokerage: before spending money, ask whether it will come back.

That sounds obvious. But I've watched plenty of developer friends trip over it, including myself when I started building independent projects, and the falls looked respectable: beautiful code, clean architecture, neat tests. Nobody used it.

Back then I got hooked on one feature. I won't say what it was; it was one of those "users definitely need this" things. I spent nearly two weeks on it, rebuilt the data structures twice, polished the interaction down to every button animation, and felt pretty proud on launch day. Then I watched the dashboard for a week. Almost nobody clicked.

It felt less like disappointment and more like books that won't balance at month end. At the brokerage, any project going to committee had the same first page: how big is the market, who pays, why us, how long to break even. Nobody approved money because a model looked pretty. Yet when it came to my own code, I skipped that page entirely, because coding is so much fun it makes you forget it's an investment too.

Development costs are easy to underestimate because they never hit the books. Spend two weeks on a feature and your bank balance doesn't drop a cent, so it doesn't hurt. But time is the principal.

Since then I've had a slightly old-fashioned rule: before any build longer than three days, write a one-page "project memo". Nothing formal, just a few questions: who will use it, how they get by today, why they'd switch to mine, and how I know they really want it. That last one is the toughest, because "I think so" doesn't count as an answer.

In finance, "how do I know they really want it" is called due diligence. You can't judge from management's story; you look at cash flow, customers, channels. For indie development, due diligence is actually simple: go where users hang out and see what they complain about, post a question, put up a one-screen landing page and see if anyone leaves an email, or just do the job by hand for a few people the clumsy way and see whether they come back.

That's how duetfolio started. I hold both US and Hong Kong stocks: two markets, two currencies, offset trading hours. Existing tools always felt a bit off, so I tracked things myself the clumsy way first. I got by like that for a long while, and only after confirming the friction showed up every day, not on a whim, did I seriously build it into a product. When I started, I was confident, because the need wasn't something I'd imagined sitting at my desk.

It's the same as doing research. A good investment thesis is rarely derived behind closed doors. Usually you spot a gap between price and value somewhere, then go verify it. Building products works the same way.

What the engineering half gave me matters just as much, and it's something finance never could. Finance people share a common flaw: deep analysis, little doing. I could write dozens of pages of industry research with crystal-clear conclusions, but I had never built a single thing for anyone to use.

The engineering idea I've gained most from is "small steps, fast, always able to roll back". At a brokerage a wrong call is expensive, so people are used to thinking it through before moving. Software is different: you can push the cost of trial and error very low. Take an idea, have a working version in half a day, ship it, see the feedback, delete it if it doesn't work. It's really finance's "limit the downside" taken to the extreme: many small bets, capped losses, uncapped upside.

The two sides keep pulling on each other. The finance half hits the brakes and asks whether it's worth it; the engineering half hits the gas and says build the smallest version and try.

My habit now goes roughly like this. When an idea pops up, I run it through the finance brain first: will anyone pay for it with money or time, can I reach those people, what's the opportunity cost? If it passes, I switch to the engineering brain: what's the smallest version that tests the demand, can I finish it in a weekend, what can I hard-code, do by hand, or leave unoptimized for now?

Since AI arrived, this accounting matters even more. Coding used to be slow, and slowness itself was a filter: things you couldn't be bothered to build simply didn't get built. Now AI can put together a complete-looking app in an afternoon, and building has almost no barrier. Without the barrier, the temptation to build for the sake of building grows. I went through a stretch of starting a new project every few days. Every one of them ran, none of them had users, and my repo list kept growing, like a retail investor who buys a pile of stocks and never looks at the fundamentals.

That period made me rethink my own motto: "Leave repetition to machines, keep the time for yourself." I used to read it wrong, thinking the point was to make machines do more work. The point is actually the second half: the time is yours, so every piece of it should go somewhere worthwhile. AI has driven down the cost of writing code. If the time it saves goes into building wheels nobody wants, you've lost the savings right back.

These days I start projects a little more slowly, but I abandon far fewer. wps-agent-skills and muse-file-bridge followed the same path: the same annoyance bugged me many times in my daily routine, and only once I was sure it would keep coming back did I start building. renqing-ledger solves a small problem, but small is fine. What matters is that I know someone needs it.

Whenever I'm about to stay up late building a feature "everyone will definitely need", I stop for half an hour and write that one-page project memo in my notes app. If the "how do I know they really want it" line is still blank, I close the laptop.