The First 30 Days of a Frontend Architecture Engagement
Week by week: what actually happens when you bring in a frontend architect
Every time I start a new engagement, I get the same question from founders: "So... what actually happens?" It's a fair question. You've hired developers before. But an architect? Less obvious.
Week 1: The Audit
I clone the repo and spend two days reading code. Not skimming — reading. I'm looking at project structure, component architecture, data flow, type safety, build tooling, and test coverage.
I'm also looking at git history. How often do developers commit? How big are PRs? Are there meaningful code reviews?
Then I do 30-minute one-on-ones with every frontend developer. "What's the most frustrating thing about this codebase?" "Where do you spend time that feels wasted?" These conversations are goldmines.
By Friday, I deliver a written audit: current state summary, identified problems ranked by impact, root causes, risk areas, and quick wins. It's 5-8 pages — not a 200-page specification.
Week 2: The Roadmap
A prioritized roadmap spanning 3-6 months. What do we fix first? What do we build as foundation? What do we migrate incrementally?
The technical roadmap has to work alongside the product roadmap. If the product needs tables with sorting and pagination in the next quarter, building a composable data table isn't debt cleanup — it's enabling the roadmap.
Week 3-4: Quick Wins
Build tooling modernization. Migrating from CRA to Vite — builds go from 45 seconds to 3 seconds. Every developer feels it immediately.
ESLint and Prettier configuration. Eliminates an entire category of code review comments.
Folder structure reorganization. Clear conventions for where things go.
One reference implementation. A feature built using the patterns we want to standardize. The living example the team references for everything after.
What Founders Should Expect
- Honest assessment. If the codebase is in rough shape, I'll say so clearly, with a plan.
- Visible progress in 30 days. Not complete transformation, but measurable improvement.
- Knowledge transfer from day one. Every PR and pairing session raises the team's level.
What Not to Expect
- A complete rewrite in 30 days
- Zero disruption (change is inherently disruptive)
- A silver bullet (architecture is one piece of the puzzle)
The first 30 days aren't magic. They're methodical — audit, plan, execute quick wins. But the team walks out with clarity they didn't have before: where the codebase is, where it's going, and how to get there.