First — the Pain
Every project starts the same way: a clean folder, the fresh scent of create-app, and ambitions that "this time everything will be beautiful." Six months later, UserCard has a romance with ProductList, Cart is jealous, builds fail on circular dependencies, and the new SuperButton looks at you like a cat at a vacuum cleaner — where does it go now?
Sound familiar? This isn't "your imagination." This is natural chaos of growth without architecture.
What is FSD and Why It Lives in My Head
Feature-Sliced Design — this isn't about "how to neatly arrange folders." This is about adult discipline. Layers and rules that allow projects to grow and you to sleep.
Since I migrated the first major frontend to FSD, I've used it everywhere. Because it removes the main question: "where does this code live?"
Layers in Simple Terms
- shared — common toolbox: UI primitives, utilities, clients
- entities — domain entities:
User,Product,Order - features — user scenarios: "log in," "add to cart"
- widgets — large blocks of features and entities:
Header,ProductGrid - pages — full pages
- app — infrastructure: providers, routing, themes
Golden rule: import from bottom to top. Reverse import — red card and "let's rewrite it."
Context of the Era
2018–2025 — rapid growth in frontend complexity: micro-frontends, design systems, dozens of feature teams in one repo. The "components folder" stopped handling scale. FSD — the answer to business problems, not just engineering:
- Reduced cost of change: fewer hidden dependencies → cheaper to modify
- Predictable onboarding: newcomers become productive faster
- Manageable release risks: layer boundaries limit the radius of failures
- Better metrics: clear ownership zones and accountability
Why FSD Works in Real Life
Predictability
Any task breaks down into "where to put it." Primitive — in shared/ui, business entity — in entities, action — in features, composition — in widgets. No need to guess.
Reuse Without Pain
Lower layers don't know about upper ones. A button from shared doesn't drag half the app with it. Surprisingly, this rule saves so many brain cells.
Team Scaling
A newcomer understands the project layout in a day. Code reviews speed up because there's no need to argue "where to put it" — the rules have already answered.
Common Pitfalls (and How We Avoided Them)
"Shoving Everything into features"
The temptation is understandable. But in a month, features becomes a dump. Don't be lazy: everything about data and models — in entities, everything reusable without business context — in shared.
"Oops, We Have Business Logic in shared"
No. shared — sterile zone. Any domain logic — in entities and features. Let shared remain a "screwdriver," not "half the device."
"We Have Layers, But No Rules"
If you don't monitor imports — FSD becomes decoration. Enable lint rules and agree in the team on what constitutes a violation. The main thing isn't literalness, but discipline.
Mini-FSD for Starters
On small projects, you don't need to stage an architectural parade. shared → features → pages is enough. Outgrow it — add entities and widgets without pain.
FSD — this isn't religion. This is a practical framework. Take the base, adjust to your needs, and don't overcomplicate where you don't need to.
When FSD Isn't Needed (and That's Normal)
- Landing pages of a couple screens
- Week-long prototypes
- One developer and short lifecycle
Conclusion
FSD gives the frontend predictability, and the team — a common language. It won't solve all problems, but it will save you from the most expensive ones: import chaos, leaked abstractions, and broken releases.
In short: FSD — this is a framework that saves time, nerves, and money. And yes, it really works when the project stops being a toy.
See also
- Slot-Me — appointment booking platform — FSD frontend in production
- PassWave — password generator — FSD even in a small product
