The reversibility test is a handy rule of thumb, though some things in the design bucket quietly turn into architecture once enough code depends on them. The styling example holds for CSS Modules versus Tailwind, but a state library or a data fetching pattern copied into 40 components is the same kind of decision, just slower to notice. Do you draw the line by cost of change today, or by the cost at the moment the choice is made?
That is a good question, Tarun.You've hit on the core nuance: small design choices often calcify into architecture through sheer volume and gravity. To answer your question: I draw the line based on the projected blast radius at the moment the choice is made, rather than just its immediate cost. If a choice defines foundational data flow (like state management or API contracts), we must anticipate that its cost of change will compound exponentially once adopted across components. Treating it as merely 'low-cost design' early on is how accidental architecture is born. The CSS/Tailwind example works because styling layers have natural boundaries and low coupling. But for data and state, a pattern copied across 40 components isn't just design anymore—it's structural. That’s why architectural governance needs to look ahead at the compounded cost, not just day-one convenience.
Tarun Sharma
React.js Frontend Web Developer | Next.js Specialist
The reversibility test is a handy rule of thumb, though some things in the design bucket quietly turn into architecture once enough code depends on them. The styling example holds for CSS Modules versus Tailwind, but a state library or a data fetching pattern copied into 40 components is the same kind of decision, just slower to notice. Do you draw the line by cost of change today, or by the cost at the moment the choice is made?