How to Be a Frontend Architect

I spent years as a developer before anyone expected me to think architecturally. I could build anything: complex forms, animation systems, and real-time dashboards. If you handed me a design, I'd ship it. But when someone first asked me to "think about the architecture," I realized I'd never had to explain why I built things a certain way, only how.

That's the shift this article is about. If you're a senior developer wondering what architectural thinking actually means, you're in the right place.

I took on my first Frontend Architect role in 2007, at AKQA, years before React or any of today's popular frameworks existed. That experience convinced me that architectural principles outlast any particular tool, and it's why this site deliberately includes patterns that work with any framework. The same thinking applies whether you're using React, Vue, or Svelte, or building without a framework at all.

I wrote this article as an introduction to the Foundations, Guides, and Patterns on this site, so you have a way to think about frontend architecture before you dive into the details. You need a practical mental model for making decisions that scale, and you don't need years of experience designing systems to build one.

This is that model.

A lot of people think architecture means drawing boxes and arrows in Miro, or choosing between microservices and monoliths. Those diagrams and decisions are what architectural thinking produces.

The way I see it, frontend architecture is about making decisions that keep an app easy to work on over the long term. Your choices affect performance, flexibility, accessibility, security, onboarding, and maintenance. Good architecture makes future work easier, while poor architecture makes the next feature harder, and the one after that harder still.

Architecture is a habit of thinking that anyone on a team can build, whatever their job title.

I've organized the material on this site into three levels that work together on real projects, and knowing how they relate to each other helps you think like an architect.

Foundations set the limits, guides set the direction, and patterns fill in the details.

In practice, developers and architects differ less in seniority or job title than in the questions they ask by instinct.

Good developers ask these questions too. Architects just ask them more often, and without anyone prompting them, so the questions are always running in the background.

Over time, you start to recognize patterns. You notice a certain folder structure and know where it leads, or a state management approach and know the debugging problems it's going to cause. You read a pull request and can tell it's going to be hard to maintain before you can explain why.

That intuition comes from years of watching decisions play out, and from dealing with the ones that went badly.

Studying architecture lets you learn from other people's scars as well as your own.

When you think in features, you focus on what needs building today. When you think architecturally, you also think about how the feature changes over time: when it grows, when it breaks, when it's reused, when the team doubles, when the product goes global, when performance becomes critical, when deadlines tighten, and when someone new joins and has to understand it quickly.

I learned this the hard way. Early in my career, I built a notification system that worked beautifully for our use case: a single application, one team, and modest traffic. I was proud of it, but then the company grew, and other teams wanted notifications too. My system assumed there'd only ever be one app using it, so the data model, the API, and the queue design were all wrong for what the company needed now. We couldn't extend it, so we replaced it, and the replacement took three times longer to build than the original because we had to migrate live data while keeping the old system running.

The feature itself worked perfectly, but I'd built it for the company as it was that year, and it couldn't grow with the company.

An architect thinks about how hard a feature will be to change later, as well as how to build it today.

The biggest difference between an architect and a senior developer who's good at coding is how they treat best practices. A best practice is meant to apply everywhere, but a tradeoff depends on your situation. "Always use TypeScript" is a best practice. "TypeScript helps when the team is big enough that unwritten agreements about data become hard to keep track of, but slows you down when you're prototyping and the types change faster than you can define them" is a tradeoff.

Every solution has a downside. Fast code might be harder to extend, flexible code might be slower, highly dynamic interfaces might be harder to cache, and a simpler design might mean fewer features.

So instead of asking which option is best, an architect asks which option will cause the least trouble over the next two years.

I've seen senior engineers treat architecture as a search for the cleanest abstraction. In my experience, the job is making a choice the whole team can work with.

A tradeoff you've chosen on purpose is better than a clever idea applied without thinking about its downsides.

I built this site as a map, and this is the order I suggest using it in.

Start with the Foundations

The Foundations help you understand your constraints: the devices you support, your performance goals, your accessibility requirements, your security policies, how you deploy, and how experienced your team is. Those tell you what's possible and what's going to take a lot of work.

Use the Guides to Choose a Direction

When you're stuck between approaches, such as rendering strategies, state management options, or ways of testing, I help you weigh the tradeoffs for your situation and make a decision.

Apply Patterns Deliberately

Once you've chosen a direction, patterns fill in the details: state management, routing conventions, data loading strategies, error boundaries, and how you organize your bundles. They help you solve the same kind of problem the same way across the whole system.

Document the Tradeoffs

A pattern chosen for speed might slow down how quickly you can ship features, and a rendering strategy chosen for performance might make the code more complex. Documenting these decisions keeps the architecture from drifting, and it helps future engineers understand why things are the way they are.

Conway's Law says that organizations design systems that mirror how their teams communicate, and in my experience it's more true than most engineers want to admit. Your architecture reflects your org chart, your team boundaries, and who talks to whom, as well as your code.

So good architecture is really about people. It keeps each part of the system small enough that developers can keep the part they're working on in their heads. It lets teams work in parallel and ship without waiting on each other or overwriting each other's changes. And it draws clear boundaries, so each team knows exactly what it owns.

I've watched teams struggle because seven people needed to coordinate on each change, even though the code itself was fine. I've seen codebases where developers always worked around the shared code instead of improving it, because no team owned it and everyone was afraid of breaking it. Those look like team problems, but the cause is the architecture.

Tools and frameworks come and go, but you'll always be building software with other people.

When I look at an architectural decision now, the first thing I ask is whether it makes working together easier or harder.

If you're taking on architectural responsibility for the first time, you can begin with a few small steps instead of refactoring your whole system:

• Identifying two constraints that shape your app today
• Deciding which direction your product should go in
• Picking one pattern you can introduce or formalize
• Documenting one recent tradeoff and sharing it with your team

Being clear about your decisions, and talking them through with your team, is how you start to have influence as an architect.

The rest of this site gives you the vocabulary, models, and techniques to design frontend systems that scale. The Foundations explain the principles behind the work, the Guides help you make decisions with confidence, and the Patterns give you practical solutions you can use right now.

Frontend architecture is a craft, and the more you practice these ways of thinking, the more natural they become. As an architect, you're expected to think clearly, communicate well, and make decisions that keep your system healthy over time, without needing to know everything.