Some of the Best System Decisions Happen During Development

One thing I’ve learned while building systems is that sometimes the better version of an idea only becomes visible while you’re already building it.

At first, I used to think changing architecture or improving flows during development meant the original plan was weak.

Now I see it differently.

Execution reveals things planning alone cannot.

Planning Is Important, But It Has Limits

Before building anything, I usually already have:

• the flow
• the structure
• the data relationships
• the intended behavior

On paper, everything can make sense.

But once the system starts becoming real, new patterns appear.

You notice:

• repeated logic
• unnecessary dependencies
• awkward user flows
• edge cases that were invisible before
• opportunities to simplify things

These are difficult to fully predict before execution.

Building Creates Context

There’s a difference between imagining a system and interacting with one while developing it.

Sometimes a feature exposes weaknesses somewhere else.

Sometimes two unrelated modules suddenly need shared behavior.

Sometimes the original flow technically works, but feels too rigid once real usage is simulated.

That added context changes how you think about the architecture.

Not because the original design was bad, but because the system is now revealing more information.

One Idea Often Leads to Another

A lot of improvements happen this way.

You build version one of something, then during development you realize:

“This could be handled in a cleaner way.”

Or:

“This part should probably become reusable.”

Or even:

“This flow should not depend on another flow.”

Those moments are valuable.

They usually come from understanding the system more deeply than you did at the beginning.

Systems Become Better Through Observation

Some architectural decisions only become obvious after friction appears.

For example:

Initial Plan
     │
     ▼
Development Begins
     │
     ▼
Patterns Become Visible
     │
     ├── Repeated logic
     ├── Workflow friction
     ├── Scaling concerns
     └── Better abstractions
     │
     ▼
Architecture Improves

That friction is useful.

It shows where the system is resisting growth.

Refactoring Is Not Failure

I think some developers are too afraid of changing their original design because they associate refactoring with mistakes.

But improving architecture during development is normal.

In many cases, it’s necessary.

Good systems are rarely built from a perfect first draft.

They evolve through:

• testing ideas
• discovering constraints
• identifying weak points
• improving structure over time

That process is part of engineering.

Overplanning Can Become a Problem Too

There’s also a point where planning too much becomes rigidity.

Trying to predict every future scenario before writing code can slow development and create unnecessary complexity.

Some things are better discovered naturally during implementation.

The important part is not avoiding change entirely.

The important part is recognizing:

• when a redesign is valuable
• when an abstraction actually helps
• and when simplicity should remain untouched

The Goal Is Better Systems, Not Protecting the Original Plan

I don’t think changing architecture during development means the first idea failed.

Sometimes it simply means the system matured.

Execution gives feedback that diagrams and documentation cannot fully provide.

That feedback is where some of the best improvements come from.

Final Thought

Some of the best engineering decisions happen while building.

Not because the planning was poor, but because development reveals relationships, patterns, and problems that only exist once the system becomes real.

That’s one of the reasons I enjoy building systems.

The process itself teaches you how the system actually wants to evolve.

Author

Jose Albert Arnedo

Full-Stack Engineer focused on ERP systems and SaaS platforms