There's a version of "move fast" that makes sense — don't over-engineer, don't polish things nobody uses, cut scope ruthlessly. That version is good advice. Then there's a different version: shipping half-understood code under deadline pressure and paying for it every week afterward. That version I've done enough of.
For the last year I've been building things slower. Not because I have more time — I don't — but because I started measuring output differently.
The thing I started measuring
I used to measure how much I shipped. Features, endpoints, screens. Then I noticed that most of what I shipped got revisited within a month. Not because requirements changed — because I'd made a decision quickly that turned out to be wrong, and the wrong decision had propagated into everything around it.
Now I measure how often I have to undo things. The goal is to make decisions I don't have to revisit.
What "slowly" actually means
It doesn't mean less code per day. It means more time before writing code at all. Writing down what the function is supposed to do before writing the function. Drawing the data flow before writing the handler. Reading the database schema before writing the query.
None of this is revolutionary. It's what they teach in university that everyone stops doing when they get a job. Turns out it works.
The tradeoff
You ship later. That's real. If the goal is a demo in two days, slow building is the wrong strategy. But for anything that will exist in three months, time spent thinking compounds faster than time spent coding.
The demo is done and gone. The decision about how auth tokens are stored is still there every time someone opens that file.
The uncomfortable part
Slow building looks unproductive from the outside. You're sitting there, not typing. On a team this takes explanation. Working alone, it takes resisting your own impatience, which is harder.
I don't have a clean answer for either. I just try to remember what the alternative felt like.