personal_asset

I Built Myself a Five-Piece System. Six Weeks Ago I Deleted the Whole Thing.

A system I built only for myself taught me the real question before building anything: not how well you built it, but whether the person receiving it — even future you — will actually want to keep using it.

一套五件套的系统,用户只有我自己,一个半月前被我全删了

A system I wrote myself. Also one I deleted myself.

Last year I built myself a full stack of software just to keep personal notes and saved material: FastAPI for the backend, Vue3 for the frontend, a worker on Redis for anything slow, PostgreSQL for storage. I went this far because I had the pieces lying around, and because I'm technical enough to feel like my own stuff should be built by me — every feature I could think of, I wanted to add.

On the night of August 3rd I sat at my computer and retired the whole thing: stopped the containers, deleted the images, wiped the database and Redis, and the folder on the server stopped existing. Nothing was broken — it all still ran. The reason for retiring it came down to one thing: from start to finish, the only person who ever used it was me, and even I didn't rely on it every day. What I actually reach for now is an existing hosted knowledge-base service, plus a small script that runs once a day.

I didn't feel any loss that night. If anything, I felt relief: all that craftsmanship, and nobody — including me — had ever paid a real price for it.

This is the piece I finally understood: whether something is worth building, worth maintaining, doesn't start with "how much care I put into the tech stack." It starts with whether the person on the receiving end — even if that's just you, a year from now — is actually willing to keep spending time on it. What I was thinking at the time was "I can carry a whole system." I never seriously asked "what do I actually need." The honest answer was something as plain as being able to save it and find it again.

Most technical people, myself included, evaluate what they're building by asking "is this technically interesting, do I enjoy writing it" before asking "what does the other side actually get out of this." A concrete version of the mistake: agonizing before launch over whether some function should be written more elegantly, without first working out whether anyone would ever click one more button because of it. There's a line that's circulated in marketing for decades, first attributed to a man named Leo McGivena, later popularized because Harvard Business School professor Theodore Levitt kept repeating it in class: nobody actually wants to buy a quarter-inch drill — what they want is the quarter-inch hole in the wall. My system was a beautifully made drill. I just never had that many holes to drill.

Now, before I add a new feature to any tool or workflow of mine, I force myself to write one sentence first: a month from now, who will do one more thing because this exists. If I can't write that sentence, the feature waits. What I want to watch next is whether this cheap trick survives a few months, or whether I just get lazy and skip it again.

Sources