What This Site Stands For

Because good software development is enjoyable.

Not always, not in every project, and not under every kind of pressure. But when a system is well structured, responsibilities are clear, data flows remain understandable, domain knowledge has a proper place, and changes do not feel like gambling, something happens that many projects almost make you forget:

Software development feels like a craft again.

Not like magic, heroics, or late-night firefighting, but like a profession you can practice well through experience, care, good tools, and clear decisions.

This site exists because I want to create more room for exactly that.

Where I come from

I do not come from theory.

I spent many years working on regulated systems. In environments where software not only has to work, but also remain understandable, maintainable, auditable, and accountable.

I have carried well-structured systems for years: not just built and handed them over, but evolved, stabilized, explained, defended, and kept them alive through countless changes.

You do not recognize a good system at the first release. You recognize it after three, five, or seven years — when people have left, requirements have changed, new regulatory constraints have appeared, teams have grown, and nobody remembers exactly why every decision was made in the first place. If the system still remains understandable, that is when its quality becomes visible.

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

And I have experienced the opposite.

In many projects, I was the firefighter called in after things were already burning: when changes caused fear, components knew everything, services had turned into miniature operating systems, stores did everything but nothing particularly well, and nobody could say where the domain logic actually lived. Systems that still ran, but that nobody was willing to claim they truly understood.

That experience shapes how I look at software. Not because I believe I know everything better, but because after enough fires, you eventually start taking fire prevention seriously.

Why this site?

Because frontend architecture is too often either underestimated or mystified.

For some people, it is just frontend: a bit of UI, a bit of state, a bit of API, a few components. It’ll be fine.

For others, architecture is something abstract: diagrams, principles, buzzwords, Clean something, conference slides, and elegant terminology with very little connection to everyday work.

Both views fall short.

Frontend architecture is neither an end in itself nor a beauty contest. It is the sum of the decisions that determine whether a system can still be understood, changed, and responsibly maintained tomorrow.

It determines whether a team stays fast or merely looks fast at the beginning. Whether domain logic remains visible or seeps into components, services, and stores. Whether new requirements are integrated or simply stuffed into the existing system. Whether a system grows — or merely swells.

This site is my attempt to write about that concretely: not neutrally, not watered down, and not as framework marketing, but from the perspective of someone who has carried healthy systems and put out fires in unhealthy ones.

What makes this site different

I do not want to build yet another site that repeats generic best practices. There are enough of those already.

I want to write about the places where architecture fails or holds up in real project work: components that suddenly start playing use cases; services that collect responsibilities like dust; stores that mix side effects, business logic, and ViewModels; reactive data flows broken by imperative shortcuts; microfrontends that do not solve missing boundaries but distribute them; regulated systems where traceability is not optional; and teams that care about quality but are never given time to sharpen the axe.

But just as much, I want to write about the opposite: clear boundaries, good names, small understandable contexts, vertical architecture, domain language, tests that create confidence, stores that actually help, interfaces that do not reveal everything, and bridges that do not romanticize legacy systems but make them changeable.

I do not only want to say what is bad. I want to show why it happens, how to recognize it, and how to find a way out.

Architecture is a craft

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

It is not.

Large parts of it are craft: clean boundaries, clear terminology, repeatable decisions, good tools, practice, discipline, feedback, mentoring, experience — and the humility not to solve every problem with supposed brilliance.

Architecture, in that sense, is not an ivory tower. It is craftsmanship and responsibility at the system level.

It does not only ask: How do I finish this feature?

It also asks: Where does this responsibility belong? What happens with the next change? How does the data flow remain understandable? What dependency am I creating here? Which decision will become difficult to reverse later? Who still needs to understand this code two years from now?

That is not slow.

That is professional.

Why AI makes this even more important

AI tooling is changing software development.

Code can be produced faster, alternatives are cheaper to explore, and prototypes appear within minutes. Agents can take on tasks, change files, write tests, make suggestions, and move large amounts of code.

That is impressive. But it does not solve architecture problems automatically.

Quite the opposite.

AI works better in clear contexts: with small modules, explicit boundaries, unambiguous responsibilities, good names, reliable tests, understandable data flows, clear architecture rules, and documented decisions.

These are not merely traditional quality attributes. They are prerequisites for AI-assisted development not to become a faster way of producing chaos.

A poorly structured system does not become easier to change simply because an agent can touch more files. When everything is wired to everything else, AI also becomes cautious, imprecise, or dangerous.

When contexts are small and boundaries are clear, however, AI can help far more effectively. It can localize changes, generate more targeted tests, reuse patterns, follow rules, explain relationships, and operate sensibly within a limited scope.

Good architecture therefore becomes no less important.

It becomes more important.

Not as nostalgia from professional craftspeople who are afraid of AI, but as the foundation that makes AI tooling reliably useful in the first place.

Not frustration. Motivation.

Of course there is frustration behind this site. Anyone who spends enough time in software projects accumulates some.

But frustration is not the core of it.

The core is the enjoyment of good software development: systems you can explain; code that does not surprise you; boundaries that protect; teams that speak the same language; tests that give you confidence; and architecture that does not get in the way, but enables change.

I do not write this site because I hate frontends.

I write it because I like good frontends.

Frontends that take domain knowledge seriously, that are not merely functional but sustainable, and that do not react to every change as if someone had only just discovered that software might need to grow.

What this site should achieve

This site should make patterns visible.

It should explain why good intentions so often produce bad systems, name anti-patterns without blaming people indiscriminately, and challenge myths without replacing them with new dogmas. It should make architecture decisions comparable, show where simple solutions are enough and where simplicity has turned into denial, and make pragmatic bridges visible when a perfect cut is too expensive, too late, or simply unrealistic.

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

But every system needs clarity about where responsibility lives, how data flows, where domain knowledge belongs, which boundaries need protection, and which shortcut will eventually come due.

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 skill, but because architecture requires a different perspective.

A developer builds solutions. An architect additionally asks whether the problem has been cut along the right boundaries.

A developer sees code quality. An architect additionally sees changeability, coupling, responsibility, risk, boundaries, and the long-term cost of decisions.

Both are needed.

This site is also not a collection of tool reviews, a framework cult, architecture folklore, or an “everything has to be clean” performance.

It is a collection of attitudes, patterns, anti-patterns, and field reports from real projects. Some lessons I learned too late, some under pressure, some through ugly bridges — but always with the aim of being a little less naive the next time.

Frontend architecture does not begin with folder structures.

It begins where components stop knowing everything.