Modular architecture: building systems that survive contact with growth

Most architecture discussions focus on what technology to use. The more important question is how much a system will cost to change in eighteen months, when the business it was built for looks different.

Modularity isn't about having many small services instead of one large one — a badly split system can be worse than a well-organized monolith. It's about drawing boundaries around the parts of the business that actually change independently, so a change in pricing logic doesn't require touching the code that handles shipping.

The systems that age well tend to hide their internal decisions behind a small, stable interface — so when the team eventually needs to replace how something works internally, the rest of the system doesn't need to know or care.

The systems that age badly usually made sense for the business at the time they were built, and then the business changed faster than anyone revisited the assumptions baked into the architecture. That's not a failure of foresight — it's a reason to treat architecture as something revisited on a schedule, not decided once.

The practical test we use with clients: pick the business change most likely to happen next year, and ask how many files someone would need to touch to support it. If the answer is "we're not sure," that's the part of the system worth investing in first.