044 | What Not to Build
the hard part now is choosing
My instinct, faced with any problem, is to build a solution for it — and lately I realized the harder skill is knowing what to leave unbuilt. Building has always been the slow, hard part, so being good at it felt like the whole job. That’s not where the hard part lives anymore. When we can stand up almost anything in an afternoon, the question worth asking stops being can I build it and becomes should I. The eye to see what’s worth building, and the nerve to drop the rest — that’s the skill I think matters most now, and the one I’m still working on.
Get the problem right first
Show an engineer a problem and we start solving it before we’ve finished hearing it. Break it down, sketch the solution, lay out a roadmap, estimate the time, weigh the risks — that reflex is most of what got us hired, and it runs deep. What it skips is the one question that decides everything downstream: was this problem worth solving at all?
A couple of years ago, working through a strategy doc with my PM, I learned to slow down on that question. My early drafts went straight at solutions. The reply was always the same blunt prompt: what’s the problem to solve, is it the prioritized one, what happens if we don’t solve it? Round after round, the doc got shorter at the top and clearer underneath. Once the problem statements were right — a few tight bullet points — every solution, trade-off, and risk fell into place around them. I’d spent years believing the solution was the work. It turned out the problem was half of it. Back then it took a PM to force that pause; the rest of us were just too busy building.
Cheap building is a trap
Now anyone can get a solution off the ground, and that’s exactly why the deciding matters more. Someone who codes daily and someone who hasn’t in years can both point Claude Code at a problem and get something working; non-engineers sketch prototypes too. That moves the bottleneck: starting the technical work is no longer the slow step, so the scarce skill becomes the judgment around it — of the ten things I could build, which one or two are worth carrying through?
The trap is that cheap building makes us want to build everything. For years we couldn’t, and now we can, and it’s intoxicating. But building fast isn’t the same as launching well. A real launch still has to earn its way out: the refinement and edge cases for a product, the scaling and reliability for infra, the privacy and safety checks. That cost doesn’t shrink because the prototype came easy. So prototype freely — that part should stay wild — but when it’s time to commit, choosing what to focus on is the actual work.
Keep making the calls
A year ago the line going around was that AI won’t take our jobs, but a coworker who uses AI will — and there’s a quieter version of that I’d watch for in myself. If we lean on AI and stop critical thinking — hand off the building, ride the flow, quit pushing back — we make ourselves easy to replace. Not by the AI, but by anyone who still thinks deeply, independently, and critically. The flip side is what we get back: with the building offloaded, we finally have the mental capacity to reason about the whole product, not just our slice of it.
Thinking harder before building sounds like a recipe for never shipping, so I keep it on a clock. I’m not after endless deliberation — just a real second thought at one moment: when I’m about to build something, do I actually want it? Ten minutes now, ten tomorrow, ten in a conversation with someone else. Half an hour across a day is usually enough to know what to cut.
We already get this practice every day, with AI handing us a stream of choices to make. Every session with a tool like Claude Code is a chain of small choices: which path, which trade-off, which suggestion to wave off. By the end of most sessions, Claude has offered me more things to build than I came in with. The most useful call I make all day is usually a no to one of them.