August 2021 accepted

Choose Incremental Architecture Over Premature Abstraction

architecturetechnical-strategypragmatismcto

Context

After ILOVEGREENER, I became more aware of the risk of designing for an imagined future too early. Early-stage products need good foundations, but they do not always need complex abstractions, heavy platforms, or architecture designed for scale that does not yet exist.

Options Considered

Design for Future Scale Immediately

Create a broad architecture that anticipates many future products, modules, and user types

Pros

Future-ready
Technically elegant
Can reduce later rework

Cons

Premature complexity
Slower delivery
May solve problems that never arrive

Build Only for Today

Optimise purely for immediate delivery and defer architectural concerns until later

Pros

Fastest execution
Low upfront effort
Good for discovery

Cons

Technical debt can compound
Harder to scale later
Risk of inconsistent patterns

Incremental Architecture

Create enough structure for maintainability while evolving architecture based on proven product needs

Pros

Balanced
Reduces waste
Supports learning and scale

Cons

Requires judgement
Needs regular review
Not as clean as a greenfield ideal

Decision

Chose incremental architecture as a leadership principle. In my current CTO role, I avoid both extremes: I do not over-engineer for hypothetical futures, but I also do not ignore the foundations that protect delivery, quality, and team scalability.

Consequences

Jun 2020

Earlier architecture choices sometimes tried to anticipate product needs before there was enough evidence those needs would matter

negative

Jan 2021

Some abstractions created maintenance overhead without delivering proportional user or business value

negative

Mar 2022

Later architecture discussions became more grounded in current risk and near-term product direction

positive

Feb 2024

The engineering function became better at distinguishing real scale problems from theoretical ones

positive