Bugs are cheap. You find one, you fix it, you ship. The decisions that actually cost millions get made in the first few weeks of a project, written down by nobody, and discovered to be wrong only when they’re nearly impossible to undo.
Architecture is just the set of decisions that are hard to change later. Get them right and the system soaks up years of growth and shifting requirements. Get them wrong and every new feature costs more than the last, until the team spends all its time fighting the system instead of improving it. The aggregate bill is well documented: large IT projects run, on average, 45% over budget and deliver 56% less value than predicted (McKinsey).
The ones that bite hardest.
- The wrong data model. Everything sits on top of how you structure your data. A model that doesn’t match how the business actually works leaks complexity into every single feature for years. This is the most expensive thing on the list to get wrong.
- Splitting things up too soon. Chopping a system into dozens of microservices before you understand the domain buys you network failures, distributed-transaction nightmares, and an operational load you never needed. Most systems should start simpler than the conference talks suggest, and the track record backs it up: small projects succeed far more often than large, complex ones (Standish via InfoQ).
- Ignoring integration reality. Systems that assume clean inputs and reliable dependencies shatter the moment they meet a real enterprise full of legacy systems and messy data.
- No clear boundaries. When everything can touch everything, one small change ripples in ways nobody predicted. Good boundaries are what let teams work, and systems grow, without constant collisions.
- Scaling for load that never shows up. Engineering for imaginary traffic burns the budget you needed for the problems you actually have.
Why it’s so easy to get wrong.
The cost is invisible at the moment you decide. Picking the convenient data model feels completely free in week two. The bill doesn’t arrive until much later, paid in slowing delivery and rising frustration, and by then unwinding it means rebuilding the foundation under a live, running system. Here’s that arc on a timeline.
timeline title Cheap now, expensive later Week 2 : Convenient choice feels free Year 1 : Features start leaking complexity Year 2 : Delivery slows to a crawl Year 3 : Rebuild the foundation under a live system
The cheapest insurance against all of this is a serious architecture review before you build, done by engineers who’ve watched these decisions play out over years. And an independent second opinion before you sign off on a vendor’s proposed design, while changing it is still a conversation and not a rebuild.
About to commit to an architecture, or already feeling one slow you down? SDCG reviews system architecture as engineers who’ve built at scale, then helps you fix the foundations before they get more expensive. We’re independent, so we’re checking the design, not selling you the next one. Book a free 30-minute review.
Sources
- McKinsey, Delivering large-scale IT projects on time, on budget, and on value
- InfoQ, Standish Group CHAOS report summary