The three signals I check first in a React codebase
I've joined teams where the React app "worked" — and still spent the first month afraid to touch anything.
After 6+ years on React and Next.js, I don't need perfect architecture on day one. I need signals that the codebase won't fight every change. Here are the three I check first.
1. I can find a feature in under a minute
Not a perfect folder tree — just consistent patterns. Pages, components, hooks, and API calls for the same feature live near each other (or follow the same rule everywhere). If every new screen is a treasure hunt, velocity dies quietly.
2. Data fetching and state follow a rule — any rule
useEffect chains, random global state, and five ways to call the API on one screen — that's the smell. I look for one obvious pattern: React Query / Server Components / a thin service layer — whatever the team picked, applied consistently. Chaos here = bugs that only show up in production.
3. Loading, error, and empty states exist on the paths that matter
Not every component needs a skeleton. But login, checkout, dashboards, anything that hits an API — if there's no loading or error UI, users will find the failure before you do. This tells me the team ships for real users, not just happy-path demos.
What I don't treat as dealbreakers on their own
- Not the latest React version or every new hook on day one
- A messy components/ folder from year one — refactor beats rewrite
- Opinions on CSS approach (Tailwind, CSS modules, styled-components) — consistency beats taste wars
The bar isn't "senior-engineer perfect." It's "can a new dev ship a safe change this week?"
What's the first red flag you spot when you open a React repo — folder chaos, state spaghetti, or missing error handling? (Or something else entirely?)