Why I stopped optimizing too early — a story in three builds

Three builds taught me the difference between performance and the performance of feeling fast.

Build one had caching layers, a message queue, and a database abstraction that could swap engines — for an app with twelve users. I shipped three weeks late, and the complexity outlived the app.

Build two was my correction: dead simple, no abstractions, direct queries. I braced for the performance cliff. It never came. At a thousand users, everything was fine. The cliff I feared was imaginary; the complexity I'd avoid was real.

Build three is where I learned the actual craft: I measured. Real traffic showed exactly two slow endpoints — one N+1 query and one missing index. Two afternoon fixes. The rest of the "optimizations" I'd been tempted to add would have been decoration.

What measuring taught me

• my guesses about slow code were wrong more often than right
• the real bottlenecks lived in two or three places, not everywhere
• simple code is easier to optimize later, because there's less of it to profile

The rule I keep now

Write the simple version. Put it in front of reality. Measure. Optimize the measured thing. In that order, always. The fog of premature optimization feels like engineering. Measurement is engineering.