How Should a Small Startup Team Structure Its Front End?
For Solo developers and small startup teams · Based on Dima's 5-Rule Front-End Architecture Evaluator
// TL;DR
Small startup teams should start with Layered Architecture — components, services, API, pages, and shared — and migrate to Vertical Slices only when pain points emerge. Dima's 5-Rule Evaluator helps you avoid the trap of adopting Feature Sliced Design or other heavyweight architectures too early. Score your project on Incremental Adoption first: if you can't justify the full structure from day one, start simple. Use the Architecture Decision Loop to add structure as your team and feature count grow.
Why do small teams over-engineer their front-end architecture?
Small teams often adopt architectures designed for large organizations because those patterns dominate blog posts and conference talks. Feature Sliced Design, for example, requires seven layers, strict import rules, and a shared vocabulary from day one. For a two-person team with five features, this is overhead that slows you down without delivering proportional benefits.
Dima's 5-Rule Evaluator prevents this mistake by scoring Incremental Adoption as a first-class criterion. If you cannot start with two or three folders and expand later, the architecture is a poor fit for your stage.
What architecture should a small startup team actually use?
Start with Layered Architecture: five folders — `components` for reusable UI, `services` for business logic, `api` for data fetching, `pages` for route-level views, and `shared` for utilities and constants. This structure scores high on Incremental Adoption and Discoverability because it is simple and familiar.
As your project grows beyond five to eight features or your team grows beyond three developers, watch for signals: merge conflicts in the same files, features scattered across all three layers, and new developers struggling to find code. These are Architecture Decision Loop feedback signals telling you it's time to migrate to Vertical Slices.
How do you migrate from Layered to Vertical Slices without rewriting everything?
Migrate incrementally. Pick the most painful business domain — the one causing the most merge conflicts or confusion. Create a folder named after that domain (e.g., `billing`). Move its components, services, and API calls into sub-folders inside `billing`. Keep the rest of your code in the original layered structure.
Repeat for the next most painful domain. Over time, your project transitions from Layered to Vertical Slices without a risky full rewrite. The 5-Rule Evaluator guides each step: after each migration, re-score cohesion and coupling to confirm improvement.
When should a small team consider Feature Sliced Design?
Almost never at the start. FSD scores poorly on Incremental Adoption because it demands the full structure from day one. It also introduces the Classification Problem — developers disagree about which layer a component belongs in — which is especially damaging on small teams where every hour counts.
Consider FSD only if your project is confirmed large and long-lived, your team is already fluent in FSD vocabulary, and you accept the classification overhead. For most small startup teams, Vertical Slices provides the same scalability benefits with far less upfront cost.
Ready to evaluate your project? Gather your project description, team size, and known pain points, then run through the 10-step workflow to get a clear, evidence-based architecture recommendation.
// FREQUENTLY ASKED QUESTIONS
Should a two-person team use Feature Sliced Design?
No. FSD requires full structure from day one, which scores poorly on Incremental Adoption — the most important criterion for small teams. Start with Layered Architecture (components, services, API, pages, shared) and migrate to Vertical Slices when your team or feature count grows enough to cause real pain points.
When should a small startup team switch from Layered to Vertical Slices?
Switch when you notice merge conflicts on the same files, features scattered across all three layers, or new developers struggling to find code. These are Architecture Decision Loop signals indicating your project has outgrown Layered Architecture. Migrate one business domain at a time to Vertical Slices.
How many features does a project need before architecture matters?
Architecture always matters, but the complexity of the architecture should match the project. Under five features with under three developers, Layered Architecture is sufficient. Beyond that threshold, evaluate whether cohesion is dropping and coupling is rising. The 5-Rule Evaluator gives you objective criteria instead of guessing.