Mid-Summer Philosophy: Keep Shipping Small

Three months into a project there is a dangerous moment. The initial excitement fades. The technical debt is visible. The urge to rewrite starts whispering. This moment killed more of my past projects than any external force.

What The Urge Sounds Like

'If I just rewrite the auth module with proper refresh rotation, then everything will be cleaner.' 'If I migrate from FastAPI to some other framework, the codebase will be modern.' 'If I redo the frontend in a new meta-framework, users will feel it.'

Each of these starts true. The end state would be cleaner. But the cost is weeks of no shipping. And the problems the rewrite solves are rarely the problems users have.

The Discipline I Hold To

Ship something small every week. Not a week goes by without a user-visible improvement, even if it is a bugfix or a polish. This forces me to work through the existing codebase rather than escape it.

July week 1: subscriber preferences page
July week 2: email open tracking
July week 3: admin bulk import
July week 4: SEO schema for articles

None of these are revolutionary. All of them are visible. All of them force me to touch the parts of the codebase that scare me, in a way that accrues value on every pass.

When Rewrites Are Actually Right

Rewrites are right when the rewrite is smaller than the accumulated workarounds. If you are working around the same problem weekly, the workaround is now the problem. Replace that module. But replace it in a week, not a quarter.

The First Principle

Code written is code shipped. Code rewritten is code not shipped. The goal is leverage in users' lives, not elegance in source files. When the two conflict, users win.

Mid-summer is when the temptation peaks. The second half of the year belongs to whoever holds the line. Keep shipping small.