Architecture takes too much time

It sounds reasonable.

“We don’t have time for architecture right now.”

Usually that doesn’t mean: We’re saving time.

Usually it means: We’re postponing decisions.

And postponed architecture decisions don’t disappear. They come back later — as coupling, as code nobody can test, as unclear ownership, as endless discussion, as fear of touching anything.

Architecture costs time. But skipping it costs time too.

It just rarely shows up in the plan up front.

The fallacy

The fallacy is treating architecture as extra work.

First comes the feature. Then comes architecture. If there’s still time.

That’s not how software works.

Every codebase ends up with a structure. Even when nobody designs one on purpose. Files end up somewhere. Components know about other things. Data flows somehow. Side effects happen somewhere. Decisions still get made — just implicitly, locally, and often contradicting each other.

So choosing not to design the architecture is not neutral either.

You still end up with an architecture. Usually an accidental one.

A big ball of mud rarely comes from one bad decision

A big ball of mud rarely appears on a Tuesday at 2:37pm because someone decided:

“Today we’re building an unmaintainable system.”

It comes from many small decisions that each look reasonable on their own.

A quick fix. An exception, just for this one feature. A dependency that’s supposed to be removed later. Reaching directly into something you’re not supposed to touch, because it’s easier right now. A component that takes on one more responsibility. A service that knows a bit more than it should.

Each decision saves time in the short term.

Together they produce a system where every change needs more and more context. At some point you’re not just trying to understand the feature — you’re trying to understand the history of every shortcut that came before it.

That’s the moment when speed collapses.

Not because the team suddenly got worse. Because the structure makes every change more expensive.

Architecture is risk management

Good architecture is not an attempt to predict the future perfectly.

That would be overengineering.

Good architecture means deliberately shaping the places where change is likely or expensive later.

Where are the domain boundaries? Who owns which state? What data is allowed into which layer? Where do side effects happen? What’s a command, what’s read state? What’s UI state, what’s business state? Which parts are allowed to know about each other — and which aren’t?

These aren’t academic questions.

These are the questions that decide whether a change stays local or spreads through half the application.

Good boundaries save work later

Boundaries cost a little attention up front.

But they save coordination later.

When it’s clear which module owns which responsibility, not every feature has to renegotiate where logic belongs. When a ViewModel is clearly separated from a DTO, not every API change has to leak all the way into the template. When side effects aren’t hidden somewhere inside components, they can be tested, observed, and reshaped.

Architecture here isn’t some giant ivory-tower diagram.

Architecture is the answer to one question:

What has to stay stable so that change stays cheap?

Overengineering is real

Of course architecture can get too big.

You can build abstractions before a problem exists. You can stack patterns to make simple things look important. You can paralyze a team with rules nobody can explain. You can turn “architecture” into an excuse for shipping nothing.

That’s real.

But overengineering is not an argument against architecture.

It’s an argument against bad architecture.

The alternative to excessive architecture isn’t no architecture at all. The alternative is lightweight architecture: visible, reviewable, practical for the team, and easy to change.

Lightweight doesn’t mean anything goes

Lightweight architecture doesn’t mean:

“Do whatever you want.”

It means:

• a few clear rules
• explicit responsibilities
• boundaries that can be checked
• short feedback cycles
• architecture decisions you can actually find in the code

A good architecture rule isn’t good because it’s written down in a document.

It’s good when it helps with everyday work: reviews, testing, refactoring, onboarding, and the next change.

The problem isn’t the first shortcut

Shortcuts are sometimes the right call.

A prototype is allowed to look different from a product. An experiment doesn’t need the same structure as a long-lived core process right away. A team is allowed to learn before it draws its final boundaries.

The problem starts when temporary decisions become permanent without anyone re-evaluating them.

Then “just this once” turns into a pattern. The pattern turns into a habit. The habit turns into architecture.

Except nobody calls it that.

The real price

A lack of deliberate architecture doesn’t make the first release expensive.

It makes the tenth change expensive.

It doesn’t make the first button hard to build.

It makes things hard once three components, two stores, a resolver, and an effect are all changing the same state at once.

It doesn’t make the first DTO dangerous.

It makes things dangerous once API shapes have leaked, unchecked, into templates, forms, and component logic.

It doesn’t make the first shortcut bad.

It becomes a problem once nobody can say which shortcuts are still in place.

The better sentence

Instead of saying:

“Architecture takes too much time.”

we should say, more precisely:

“We need to decide how much structure this problem needs right now, so we can still change it later.”

That’s a different discussion.

It’s less dogmatic. It’s less heroic. And it’s a lot more honest.

Architecture isn’t an end in itself. Architecture also isn’t a substitute for understanding the product.

But skipping architecture isn’t speed.

It’s borrowing against the future.

And the big ball of mud is the bill coming due.