Seven Things I Learned from Building
Mostly by doing the wrong version first
I didn't come from a CS background. I just kept building long enough to start noticing the same mistakes show up twice.
Here are seven of them. Most I learned by doing the wrong version first, which is the slow way to learn anything and also the only way it sticks.
01The hard part is deciding what to build
The building isn't the bottleneck anymore. Claude Code and Codex get you most of the way in an afternoon. So the constraint moved. Building got cheap. Deciding what's actually worth building didn't.
My rule now: I have to write it as one sentence before I open anything. "This does X for Y." If I can't finish that sentence, the idea isn't ready and I don't start.
02Start smaller than feels reasonable
Now that building is fast, everything wants to be big, because a big idea feels basically free to start. It isn't. A bigger first version just means more things you can be wrong about, and you find that out later, after you've sunk the time.
So I cut the idea down until it feels almost too small to bother with. One feature, one user, one thing it does. If that works I keep pulling. If it doesn't, I found out in a day instead of three weeks.
03Ship the first time it works, not the first time it's good
Shipping teaches you something polishing can't: how someone actually uses the thing. No amount of tweaking gives you that. Every extra day of polish is a day you don't have the only information that matters.
If I can get through it end to end once without it breaking, it goes out. Whatever's ugly after that, I fix against real feedback instead of guessing.
04Notice when you're doing fake work
A lot of what feels like work is avoidance wearing a productive costume. Renaming variables. Redoing spacing that was fine. Reorganizing files that already worked. You feel busy and nothing moves.
When that happens I stop and ask what I'm avoiding. The answer is almost always the actual task. Usually it's the hard part, or the part where I'd have to show it to someone.
05Design is part of whether it works
I came from a creative and video background, so this one was obvious to me before the code was. People decide how they feel about something in about a second. If it looks broken, they assume it is, before they ever try it.
At some point I stop adding features and go fix spacing, hierarchy, and what the eye lands on first. Fewer things, arranged clearly, usually beats more things in a pile every time.
06If it's hard to explain, it's probably too complex
Every extra feature feels like progress and adds a new way for things to break. I've rebuilt simpler versions of almost everything I've made. The v2 is usually the v1 with half the parts taken out.
07Build from friction, not from ideas
Everything I've actually finished started as something that annoyed me. Ideas are easy to have and easy to drop, because nothing pulls you back to them. A real annoyance keeps pulling.
So I stopped collecting "good ideas" and started fixing small things that get in my way. Those are easy to scope, easy to test, and I already know at least one person wants it. Me.
That's most of it. I'll probably rewrite half of these once I figure out why they're wrong.