The product decisions that haunt you

Every application has scars—places where a technical decision made under time pressure became a permanent constraint on what the product can do. I've made enough of them to have opinions about which ones hurt most.

The Database Design You Can't Undo

Schema changes are cheap in development and expensive in production. Storing prices as strings instead of integers. Using a single data JSON column for everything instead of proper columns. These decisions compound.

The most painful one I've seen: a flat user table that assumed a user had one role, at a company that eventually needed multi-role users. The migration took weeks and touched hundreds of queries.

Spend an extra hour on schema design before the first migration. It's the cheapest time you'll ever buy.

The API You Have to Support Forever

Once external clients depend on your API, you can't break it. The field you named user_name instead of username. The pagination scheme that doesn't support cursor-based navigation. The response format that doesn't include metadata clients will eventually need.

Version your API from day one. Design your response shapes as if you'll regret them. You probably will, and a version number is the cheapest escape hatch.

The Library That Owned You

Picking a UI component library or a state management solution locks you into its mental model. When that library stops being maintained or the ecosystem moves on, the migration cost can be enormous.

Favor thin dependencies—libraries that do one thing and get out of the way—over frameworks that own large parts of your architecture.

The Question Worth Asking

Before every significant technical decision: 'How hard will it be to change this in a year?' The decision itself might be right. But knowing the reversal cost shapes how confident you need to be before committing.