The Architecture Decisions That Are Hard to Reverse

Early in a product's life, almost every decision feels equally weighty. It isn't. Some choices — a component library, a CSS approach, a naming convention — cost an afternoon to reverse. Others quietly calcify into the foundation of everything built on top of them.

The decisions worth slowing down for

Your data model. Renaming a function is a find-and-replace. Restructuring how your core entities relate to each other after you have real production data is a migration project with real risk of downtime and data loss.

Your auth boundary. Whether sessions live in a cookie, a token, or a third-party provider shapes every feature you build afterward, from mobile apps to webhook security. Retrofitting this later usually means touching every protected route in the codebase.

Your multi-tenancy strategy. Shared schema versus isolated databases per customer is a decision that gets exponentially more expensive to change as your customer count grows. We've seen teams spend a full quarter migrating this after the fact — a quarter that could have been avoided with a single planning session before the first customer signed up.

The decisions that don't deserve the anxiety

Framework choice within reason, file structure, state management library — these are all real decisions with real trade-offs, but they're refactors, not rewrites. Teams that spend weeks debating whether to use one flavor of state management over another are usually avoiding the harder, more consequential conversation about their data model.

Our rule of thumb: if reversing a decision requires a migration that touches live customer data, it gets a design document and a second set of eyes. Everything else gets a pull request.