What This Site Stands For

I like good software engineering. Especially when it does not feel like gambling.

When a system has clear boundaries, responsibilities are easy to locate, data flows remain understandable, and domain logic has a place of its own, the work changes. Changes do not suddenly become trivial, but they become understandable. You can explain decisions, narrow down failures, and add new requirements without rediscovering half the system every time.

That is when software development starts to feel like a craft again.

Not magic, heroics, or late-night firefighting. Just a profession that can be practiced well with experience, care, decent tools, and clear decisions.

That is what I want to make a little more room for on this site.

Where I Come From

Most of what shaped my view of architecture came from real projects.

I spent many years working on regulated systems. In that kind of environment, it is not enough for software to work today. It also has to remain understandable, maintainable, testable, and accountable.

I did not just build systems and hand them over. I stayed with them for years, extended them, stabilized them, explained them, defended architectural decisions, and carried them through countless changes.

That is why I rarely judge a system by its first release. The interesting part starts three, five, or seven years later. People have left. Requirements have changed. Regulations have been added. Teams have grown. At some point, nobody remembers exactly why a decision was made the way it was.

If the system is still understandable and changeable at that point, quite a few things were probably done right.

I know how enjoyable it can be to work in systems like that. I also know the other side.

In some projects, I was the person called in when things were already burning. Changes had become frightening, components knew everything, services had turned into small operating systems, and stores were doing a great many things without doing any of them particularly clearly. Eventually, nobody could convincingly explain where the domain logic actually lived.

The systems were still running. Sometimes that was already the nicest thing one could say about them.

Those experiences shaped the way I think about architecture. Not because I believe I know better than everyone else. After enough fires, you simply start taking fire prevention more seriously.

Why This Site?

Frontend architecture is often either underestimated or made unnecessarily mystical.

For some people, it is just frontend. A bit of UI, some state, a few APIs and components. It will probably be fine.

For others, architecture begins when diagrams, principles, buzzwords, and the latest version of “Clean Something” appear.

Both views miss the point.

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

Those decisions influence whether a team stays fast over time or merely looks fast at the beginning. They determine whether domain logic remains visible or slowly disappears into components, services, and stores. New requirements can either be integrated into the system or squeezed into whichever place happens to have room.

A system can grow. It can also simply get fatter.

That difference is what I want to write about here. Concretely, sometimes quite directly, and preferably without framework marketing. My perspective comes from systems that worked well and from systems where, eventually, the only thing that still worked reliably was the firefighting.

What I Want to Write About

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

I am interested in the places where architecture either holds up in day-to-day project work or quietly starts to fall apart. Components begin acting like complete use cases. Services accumulate responsibility like dust. Stores mix side effects, business logic, and view models. Reactive data flows become harder to understand because imperative shortcuts keep cutting across them. Microfrontends do not solve missing boundaries; in the worst case, they simply distribute the same problem across multiple deployments.

Then there are regulated systems, where traceability is not optional, and teams that genuinely care about quality but are rarely given enough time to sharpen the axe.

I am just as interested in the opposite. Clear boundaries, good names, and small, understandable contexts make an enormous difference. Domain language helps. Tests create confidence. Stores can be extremely useful when they have a clearly defined job. Good interfaces reveal no more knowledge than they need to. And sometimes a legacy system does not need a perfect solution first. It needs a sensible bridge that makes the next step possible.

So I do not only want to point at what went wrong. The more interesting questions are why it happened, how to recognize it, and how to get out again.

Architecture Is Craft

Software development is sometimes treated as if it were a form of magic.

Most of it is much less glamorous.

Good software is often built through fairly ordinary things: clear terminology, understandable boundaries, good tools, practice, feedback, mentoring, experience, and the discipline not to solve every problem with an especially clever idea.

That is why I do not see architecture as an ivory-tower activity. It is craftsmanship applied at system level.

Of course, a feature still has to get finished. Architecture simply adds a few more questions. Where does this responsibility belong? What happens when the next change arrives? How do we keep the data flow understandable? What dependency are we creating here? Which decision will be painful to undo later? And who will still need to understand this code two years from now?

That does not automatically make development slow.

At its best, it simply prevents us from confusing short-term throughput with sustainable speed.

Why AI Makes This Even More Important

AI tooling is already changing software development in very visible ways.

Code can be generated faster. Trying alternatives is cheaper. Prototypes appear in a fraction of the time. Coding agents can analyze tasks, modify files, run tests, make suggestions, and now carry surprisingly large changes through a repository.

I find that impressive, and I use these tools intensively myself. Architecture problems, however, do not disappear because of it.

Clear contexts are useful not only for people. AI systems also work better when modules are manageable, responsibilities are explicit, names make sense, and tests and architecture rules provide useful feedback.

A poorly structured system does not become easier to change simply because an agent can touch more files at once. If everything is connected to everything else, AI may just reproduce that problem faster.

When boundaries are clear, the working space becomes smaller and more manageable. An agent can localize changes more reliably, recognize existing patterns, use tests more effectively, and operate within a constrained context.

So I do not think good architecture becomes less important in the age of coding agents. I think part of the reason for it changes.

It is not just something for people who romanticize professional craftsmanship and miss the good old days. Clear boundaries, explicit knowledge, and executable rules also make agentic work more reliable.

Why I Write About This

Of course there is some frustration behind this site. Spend enough years working on software and you will collect some automatically.

But that is not the main reason I write.

The main reason is that I genuinely enjoy good software engineering.

I like systems that can be explained. Code that does not surprise you every time you change it. Boundaries that actually protect something. Teams that use the same language. And tests that let you ship a change with a little more confidence and a little less prayer.

I like architecture when it enables change instead of getting in the way of it.

So I do not write this site because I dislike frontend development. Quite the opposite. I like frontends that take domain logic seriously and are built for more than today. Systems that can grow without reacting to every new requirement as if nobody had ever considered that software might change.

What This Site Should Do

This site should make patterns visible.

I want to explain why good intentions sometimes produce bad systems. Anti-patterns should have names, but those names should not automatically become judgments about the people who created them.

I want architectural decisions to become easier to compare. I am interested in places where a simple solution is completely sufficient, and equally in places where supposed simplicity merely means postponing a problem for another few months.

Not every situation needs the perfect solution.

Sometimes a clean cut is too expensive. Sometimes the insight arrives too late. Sometimes you need to build a bridge before an existing system becomes changeable again at all.

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

Every system does need a minimum level of clarity about where responsibility lives, how data flows, where domain logic belongs, and which boundaries actually matter.

Shortcuts are perfectly fine too.

It just helps to know which ones are likely to send an invoice later.

What This Site Is Not

This is not developer bashing.

A good architect is not automatically the better developer. And an excellent developer does not automatically become a good architect. They are different areas of focus.

Development requires technical depth, precision, and the ability to build good solutions. Architecture broadens the view toward responsibilities, boundaries, coupling, changeability, risk, and the long-term consequences of technical decisions.

In good teams, those strengths complement each other.

Sometimes the strongest developer on the team is not the architect. That is not a problem at all. Those combinations can work exceptionally well when both sides bring their strengths and take each other seriously.

This site is therefore neither a collection of tool reviews nor framework worship. It is not architecture folklore, and it is certainly not an “everything must be clean” theatre performance.

It is a collection of experiences, viewpoints, patterns, anti-patterns, and field reports from real projects. Some things I understood early. Others took considerably longer. Some lessons came under pressure, and some came through fairly ugly intermediate solutions.

The goal is not to get everything right next time.

Being a little less naive would already be a good start.

For me, frontend architecture does not begin with folder structures.

It begins when components stop knowing everything.