Module boundaries and dependencies
Where features, shared code, and infrastructure leak into each other — and where the seam should be instead.
For React & TypeScript teams
Your frontend is shipping. Changing it is the problem.
A focused Frontend Architecture Review for products where every meaningful change now crosses too many components, hooks, folders, and decisions. I separate urgent risks from harmless mess and give your team a practical plan for what to change next.
React · TypeScript · complex forms · data-heavy UIs · design systems
The delivery problem
The warning signs are usually obvious. The next move isn't.
01
A small UI change turns into a repository-wide search.
02
Shared components have become the place where every exception goes.
03
State, validation, and server data are coupled until nobody knows what owns what.
04
A rewrite is being discussed because the team cannot see a safer path.
None of these automatically means “rewrite the frontend.” But they do mean the team needs a shared diagnosis before the next large feature makes the situation worse.
The offer
This is not a generic code review.
I look at the decisions that make future delivery easier or harder: boundaries, dependencies, data flow, state, UI reuse, and the way the team can safely evolve the code. The outcome is a prioritised architecture map your team can use — not a document full of lint-style comments.
A shared diagnosis
What is structural, what is local, and why it matters.
A prioritised plan
The few changes worth making first, with trade-offs and dependencies.
A team-ready explanation
Language and diagrams that help engineers and stakeholders make the same decisions.
What I review
The parts of frontend architecture that make change expensive.
State and data flow
Ownership, asynchronous state, cache boundaries, forms, and side effects that have become coupled over time.
Component and design-system seams
Whether reuse is helping the product or making ordinary changes unexpectedly expensive.
Complex workflows
Validation, permissions, error states, optimistic UI, and recovery paths where the architecture gets tested for real.
Delivery friction
The places where the current architecture makes testing, reviews, onboarding, or safe releases harder than they need to be.
I won't recommend a rewrite because a folder structure looks unfashionable. The review focuses on problems that affect delivery, reliability, or the team's ability to reason about change.
How it works
Start with the question that is blocking the team.
- 01
Context first
We start with the product, delivery problem, constraints, and the parts of the frontend that worry you.
- 02
Focused review
I inspect the agreed scope and trace the decisions behind its structure, dependencies, and workflows.
- 03
Working session and plan
You get a clear walkthrough, a prioritised set of recommendations, and time to challenge the trade-offs together.
The scope should be small enough to produce decisions, not a report that nobody has time to use.
Deliverables
A plan your team can actually use.
- An architecture map of the reviewed area.
- Concise findings with evidence and severity.
- A prioritised improvement plan: now, next, later.
- Recommended seams and a migration sequence.
- A walkthrough where the team can challenge the trade-offs.
The exact scope and format are agreed after we understand the product and the question your team needs answered.
Fit
Useful when the problem is real — not hypothetical.
A good fit if
- You have a live React/TypeScript product and a real delivery problem.
- Several engineers touch the frontend or need to make shared decisions.
- You want a practical next step, not architecture theatre.
- You can give enough product and code context for a meaningful review.
Not the right fit if
- You only need a few visual tweaks or a one-off bug fix.
- The expected outcome is a guaranteed rewrite plan before anyone has seen the code.
- You want an audit across every system in the company with no focused question.
Relevant experience
Enterprise architecture work, grounded in how teams actually ship.
My work has included an architecture role on a Procter & Gamble enterprise project. One recurring lesson from that environment — and from later work with AI coding agents — is that a system only becomes easier to change when its architectural intent is explicit enough for both people and tools to follow.
Read the article
See selected work Designing Project Documentation for AI Coding Agents
How explicit architecture and project context make AI-generated changes safer in enterprise codebases.
More writingBuilding Design Systems That Scale
How I think about UI systems that teams can keep changing.
FAQ
A few useful questions before we talk.
Do you need access to the whole repository?
Not necessarily. The initial conversation defines a focused area: a workflow, a feature boundary, a shared platform concern, or another problem that is currently slowing the team down.
Can this work for a legacy codebase?
Yes. The point is not to make an older codebase look fashionable. It is to find a safer sequence of decisions that makes the next meaningful change easier to ship.
Will you recommend a rewrite?
Only if the evidence supports it. Most teams need a clear incremental path first; a rewrite is not a default recommendation or a substitute for diagnosis.
What happens after the review?
Your team can use the plan independently, or we can discuss a separate, clearly scoped follow-up. The review itself is designed to leave you with useful decisions either way.
How do we decide the scope?
Start with the product area where change has become expensive or risky. In the initial conversation, we use that problem, the available context, and the team’s decision deadline to agree a focused review that can lead to a useful plan.
Start with context
You don't need a perfect frontend before the next feature. You need a clear next decision.
Tell me what is becoming difficult to change, what the team has already tried, and which product area matters most. I'll reply with a suggested scope for a focused architecture review.
Prefer a short introductory call? Request one by email.I usually respond within 24–48 hours.