How to Be a Frontend Architect
A guide for senior engineers becoming architects
I spent years as a developer before anyone expected me to think architecturally. I could build anything: complex forms, animation systems, real-time dashboards. Hand me a design and I'd ship it. But when someone first asked me to "think about the architecture," I realized I'd never had to answer why I built things a certain way, only how.
That's the shift. And 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 shaped my conviction that architectural principles outlast any particular tool. It's why this site deliberately includes patterns that work regardless of framework. The underlying thinking applies whether you're using React, Vue, Svelte, or building without a framework entirely.
I wrote this article to sit above the Foundations, Guides, and Patterns on this site, giving you a way to think about frontend architecture before you dive into the specifics. You don't need years of experience designing systems. You just need a practical mental model for making decisions that scale.
This is that model.
What Frontend Architecture Actually Is
There's a persistent myth that architecture means drawing boxes and arrows in Miro, or choosing between microservices and monoliths. Those are outputs of architectural thinking, not the thing itself.
The way I see it, frontend architecture is the discipline of making decisions that reduce long-term cost. Every choice you make affects 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 even worse.
Architecture is not a title. It is a habit of thinking.
Three Levels of Architectural Thinking
I've organised the material on this site into three levels that work together to support real projects. Understanding the relationship between them is the first step to thinking like an architect.
Foundations
Where I explore the philosophical underpinnings, the why behind architectural decisions. They cover what the platform gives you, what users need, how teams collaborate, what the browser guarantees, and what performance allows. These are the constraints you cannot escape, and the principles that help you navigate them.
Explore FoundationsGuides
Decision frameworks that address the when and which. When you're choosing between rendering strategies, figuring out how to structure your tests, or deciding on a CSS approach, I walk through the tradeoffs and help you make a call. They're opinionated, and they're meant to unstick you.
Browse GuidesPatterns
The how, offering specific and repeatable solutions to common problems at the component, feature, or system level. They reduce cognitive load by giving names to ideas that have proven useful many times before. You don't read them cover to cover; you reach for them when you need them.
View PatternsTogether, these three layers structure your thinking. Foundations set the limits, guides set the direction, and patterns fill the details.
The practical difference between a developer and an architect isn't seniority or job title. It's the questions they instinctively ask.
Developers ask: How do I implement this?
Architects ask: How will this implementation constrain our future options?
Developers ask: What's the best library for this?
Architects ask: What's the cost of removing this library in two years?
Developers ask: Does this work?
Architects ask: Does this fail gracefully?
Developers ask: Can I ship this?
Architects ask: Can someone else maintain it?
None of these questions are exclusive to architects, and good developers ask them too. The difference is frequency and instinct. Architectural thinking means these questions are always running in the background, not just when someone prompts you to consider them.
Over time, this becomes pattern recognition. You see a certain folder structure and know where it leads. You spot a state management approach and can predict the debugging nightmares. You read a pull request and feel the future maintenance burden before you can articulate why.
That intuition isn't magic. It's accumulated scar tissue from watching decisions play out over years. The goal of studying architecture is to learn from other people's scars, not just your own.
The Questions Architects Ask
Think in Lifecycles, Not Features
Feature thinking is local, focused on what needs to be built today. Architectural thinking is temporal. It asks what the feature looks like 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 must 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, modest traffic. I was proud of it. Then the company grew. Other teams wanted notifications too, but my system assumed a single consumer. The data model was wrong. The API was wrong. The queue design was wrong. We didn't extend it; we replaced it, and the replacement took three times longer than the original because we had to migrate live data while keeping the old system running.
The feature worked perfectly. The architecture failed completely. I'd solved for today and created a wall for tomorrow.
Architects design the future cost of a feature, not just the implementation of it.
Here's where architectural thinking diverges most from being a senior developer who's good at coding.
Best practices are context-free, while tradeoffs are context-aware. "Always use TypeScript" is a best practice. "TypeScript adds value when the team is large enough that implicit contracts become a communication bottleneck, but adds friction when you're prototyping and the types are changing faster than you can define them" is a tradeoff.
There are no perfect solutions, only tradeoffs. Fast code might be harder to extend. Flexible code might be slower. Highly dynamic interfaces might be harder to cache. Simplicity might cost you features.
Architectural thinking means asking a different question. Not "which option is best?" but "which option hurts the least over the next two years?"
I've seen senior engineers believe architecture is about finding the cleanest abstraction. In my experience, it's about making a choice the whole team can live with. A tradeoff made deliberately is better than a clever idea applied blindly.
Tradeoffs, Not Best Practices
How to Use This Site
I've built this site as a map, and here's how I'd suggest using it.
Start with the Foundations
Look at your constraints: device targets, performance, accessibility requirements, security policies, deployment model, and team maturity. These tell you what's possible and what's expensive.
Use Guides to choose direction
When you're stuck between approaches, whether rendering strategies, state management options, or testing philosophies, I help you weigh the tradeoffs for your specific context and make a call.
Apply Patterns deliberately
Once the direction is set, patterns fill in the structure: state management, routing conventions, data loading strategies, error boundaries, and bundle organisation. They help you solve the same class of problem consistently across the whole system.
Document the tradeoffs
A pattern chosen for speed might slow down feature velocity. A rendering strategy chosen for performance might increase complexity. Writing these down prevents architectural drift and helps future engineers understand why things are the way they are.
Scaling People, Not Code
There's a saying that organisations design systems which mirror their own communication structures. It's called Conway's Law, and it's more true than most engineers want to admit. Your architecture doesn't just reflect your code; it reflects your org chart, your team boundaries, and who talks to whom.
This means good architecture is fundamentally about people. It reduces cognitive load so developers can hold the relevant part of the system in their heads. It enables safe parallel work so teams can ship without waiting on each other or stepping on each other's changes. It creates clear boundaries so ownership is obvious and responsibility doesn't diffuse into nobody's job.
I've watched teams struggle not because the code was bad, but because seven people needed to coordinate on every change. I've seen codebases where the fastest path was always to route around the shared code rather than improve it, because nobody owned it and everyone feared breaking it. These aren't technical problems. They're architectural failures that manifest as team dysfunction.
Tools and frameworks change, but people remain. The best architectures are the ones that help people succeed together. When I evaluate an architectural decision now, the first question I ask isn't 'is this elegant?' It's 'does this make collaboration easier or harder?'
If you're stepping into architectural responsibility for the first time, you don't need to refactor your entire system. Start small.
- Identify two constraints that shape your app today.
- Decide which direction best describes where your product should go.
- Pick one pattern you can introduce or formalise.
- Document one recent tradeoff and share it with your team.
Architectural influence begins with clarity and communication.
Where to Begin Tomorrow
What Comes Next
The rest of this site gives you the vocabulary, models, and techniques to design frontend systems that scale. Explore the Foundations for the principles behind the work, the Guides to navigate decisions with confidence, and the Patterns for practical solutions you can use right now.
Frontend architecture is a craft, and the more you practise these ways of thinking, the more natural it becomes. You're not expected to know everything. You're expected to think clearly, communicate well, and make decisions that keep your system healthy over time.
That is the work of an architect.
A Monthly Email
from Den Odell
Behind-the-scenes thinking on frontend patterns, site updates, and more