Why?

Because good software development is genuinely fun.

Not always. Not in every project. Not under every kind of pressure or in every kind of system.

But when a system has clear boundaries, responsibilities are explicit, data flows stay understandable, business logic has a place to live, and changes don’t feel like a gamble — software development becomes something many projects have almost forgotten:

It feels like a craft again.

Not magic.
Not heroism.
Not a midnight fire brigade.
But a profession you can actually do well — with experience, care, good tools, and clear decisions.

This site exists because I want to reclaim some space for exactly that.

Where I come from

I don’t come from theory.

I have spent many years working in regulated systems — environments where software doesn’t just have to work, but must remain understandable, maintainable, auditable, and accountable.

I have carried clean systems over years. Not just built and handed off, but evolved, stabilised, explained, defended, and kept comprehensible through many rounds of changing requirements.

A good system doesn’t reveal itself at the first release.

You see it after three years.
After five years.
After seven years.
When people have left.
When requirements have shifted.
When regulatory demands have been added.
When teams have grown.
When nobody can quite remember why every decision was made the way it was — and the system is still understandable anyway.

I have experienced how enjoyable it can be to work in a system like that.

And I have experienced the opposite.

I have been the firefighter in many projects.
Called in when things were already burning.
When changes caused fear.
When components knew everything.
When services had grown into small operating systems.
When stores did everything and nothing well.
When nobody could say where the business logic actually lived.
When the system was still running, but nobody would claim to really understand it.

That experience shapes how I see things.

Not because I think I know better.
But because after enough fires, you start taking fire prevention seriously.

Why this site?

Because frontend architecture is too often either dismissed or mystified.

For some people, it’s just frontend.

A bit of UI.
A bit of state.
A bit of API.
Some components.
It’ll be fine.

For others, architecture becomes something abstract.

Diagrams.
Principles.
Buzzwords.
Clean something-or-other.
Conference slides.
Pretty concepts far removed from day-to-day work.

Both miss the point.

Frontend architecture is not an end in itself.
It’s not a beauty contest either.

It is the sum of decisions that determine whether a system can still be understood, changed, and owned tomorrow.

It determines whether a team stays fast or just looks fast at the start.
It determines whether business logic stays visible or seeps into components, services, and stores.
It determines whether new requirements get integrated or just crammed in.
It determines whether a system grows — or just swells.

This site is my attempt to write about this concretely.

Not neutrally.
Not softened.
Not as framework marketing.
But from the perspective of someone who has carried clean systems and put out burning ones.

What’s different here

I don’t want to build another site that repeats general best practices.

There’s enough of that already.

I want to write about the places where architecture actually fails or holds in real projects.

About components that start playing the role of use cases.
About services that accumulate responsibility like dust.
About stores that mix side effects, business logic, and view models.
About reactive data flows broken by imperative shortcuts.
About microfrontends that don’t resolve boundaries but distribute missing ones.
About regulated systems where traceability is not optional.
About teams that want quality but never get time to sharpen the axe.

But also about the other side:

About clean cuts.
About good names.
About small, understandable contexts.
About vertical architecture.
About domain language.
About tests that build trust.
About stores that actually help.
About interfaces that don’t leak everything.
About bridges that don’t paper over legacy but make it changeable.

I don’t just want to say what’s bad.

I want to show why it happens, how to recognise it, and how to get out.

Architecture is craft

Many people talk about software development as if it were magic.

It isn’t.

Most of it is craft.

Clean cuts.
Clear concepts.
Repeatable decisions.
Good tools.
Practice.
Discipline.
Feedback.
Mentoring.
Experience.
And the humility not to try to solve every problem with cleverness.

In that sense, architecture is not an ivory tower.

It is craft-level responsibility at system scale.

It doesn’t just ask:

How do I get this feature done?

It also asks:

Where does this responsibility belong?
What happens with the next change?
How does the data flow stay understandable?
What dependency is being created here?
Which decision will be hard to reverse later?
Who still needs to understand this code in two years?

That’s not slow.

That’s professional.

Why AI makes this more important, not less

AI tooling is changing software development.

Code gets generated faster.
Variants become cheaper.
Prototypes appear in minutes.
Agents can take on tasks, edit files, write tests, make suggestions, and move large amounts of code.

That’s impressive.

But it doesn’t solve architecture problems automatically.

Quite the opposite.

AI works better in clear contexts.

Small modules.
Explicit boundaries.
Unambiguous responsibilities.
Good names.
Solid tests.
Understandable data flows.
Clear architectural rules.
Documented decisions.

These are not just classic quality attributes.

They are prerequisites for AI-assisted development to produce something better than faster chaos.

A poorly structured system doesn’t become easier to change just because an agent can touch more files.

When everything is wired to everything, AI becomes cautious, imprecise, or dangerous.

When contexts are small and boundaries are clear, AI can help much more effectively:

It can localise changes.
It can generate tests more precisely.
It can reuse patterns.
It can follow rules.
It can explain relationships.
It can do meaningful work in a bounded space.

Clean architecture doesn’t become less important because of AI.

It becomes more important.

Not as nostalgia from craftspeople who fear AI.

But as the foundation that makes AI tooling reliably useful at all.

Not frustration. Motivation.

Of course there’s some frustration in this site.

Work in software projects long enough and you collect it inevitably.

But frustration is not the core.

The core is a genuine love for good software development.

For systems you can explain.
For code that doesn’t surprise.
For boundaries that protect.
For teams that speak the same domain language.
For tests that give courage.
For architecture that doesn’t get in the way but enables change.

I don’t write this site because I hate frontends.

I write it because I like good frontends.

Frontends that take business logic seriously.
Frontends that don’t just work but can carry change.
Frontends that don’t act, on every modification, as if this is the first time anyone has discovered that software might need to grow.

What this site is trying to do

This site wants to make patterns visible.

It wants to explain why good intentions often produce bad systems.
It wants to name anti-patterns without dismissing people wholesale.
It wants to dismantle myths without building new dogmas.
It wants to make architectural decisions comparable.
It wants to show when simple solutions are enough and when simplicity is just avoidance.
It wants to show bridge solutions — when a perfect cut is too expensive, too late, or simply not realistic.

Not every project needs DDD.
Not every team needs microfrontends.
Not every application needs a store.
Not every problem deserves a framework.

But every system needs clarity about:

where responsibility lives,
how data flows,
where business logic lives,
which boundaries must be protected,
and which shortcut will become a bill later.

What this site is not

This is not developer bashing.

Good developers are valuable. Good senior developers even more so.

But a good developer is not automatically an architect. Not because they lack ability, but because architecture demands a different perspective.

A developer builds solutions.

An architect also asks whether the problem has been cut correctly.

A developer looks at code quality.

An architect looks at changeability, coupling, responsibility, risks, boundaries, and the long-term cost of decisions.

Both are needed.

This site is also not a tool review collection.
No framework cult.
No architecture folklore.
No ‘everything must be clean’ theatre.

It is a collection of attitudes, patterns, anti-patterns, and field reports from real projects.

Some learned too late.
Some learned under pressure.
Some accompanied by ugly but honest bridge solutions.
But all with the same intent: to be less naive next time.

Frontend architecture doesn’t begin with folder structures.

It begins where components stop knowing everything.