Written by Mico Ang
Architecture should make change safer
Good frontend architecture is not measured by how many abstractions it introduces. It is measured by how confidently a team can change the product.
As products grow, frontend code absorbs pressure from every direction: new workflows, changing business rules, design revisions, analytics requirements, accessibility improvements, and backend contracts that continue to evolve. The goal is not to predict every future requirement. The goal is to create boundaries that keep those changes understandable.
Start with responsibility, not folder names
I organize frontend systems around clear ownership:
- UI primitives own repeatable visual behavior and accessibility.
- Feature components own a user workflow or product capability.
- Data adapters translate API responses into stable frontend shapes.
- Page-level composition decides how features work together.
This separation prevents a visual component from quietly becoming responsible for API calls, permissions, validation, analytics, and business rules at the same time.
Build a small, useful design system
A design system should solve repeated decisions, not create ceremony. I begin with the pieces that carry the most product risk: typography, spacing, buttons, form fields, feedback states, dialogs, tables, and responsive containers.
The important part is the contract. A shared component should provide sensible defaults, accessible behavior, and a controlled way to extend it. Teams move faster when they do not need to rediscover focus states, loading behavior, or mobile spacing on every screen.
Keep state close to the problem
Not every value belongs in global state. Local interface state should stay near the component that uses it. Server state should have clear loading, success, empty, and failure behavior. Shared workflow state should become global only when multiple parts of the application genuinely coordinate around it.
That discipline makes code easier to trace and reduces accidental coupling.
Leadership means improving the path for the next change
Technical leadership is not only choosing tools or reviewing pull requests. It is making the system easier for other people to understand. That means documenting the decisions that matter, removing unnecessary complexity, and giving teammates patterns they can use without waiting for permission.
The best architecture is rarely the most impressive diagram. It is the one that lets a team ship the next important change with clarity, confidence, and fewer surprises.