Feature-Sliced Design is a frontend architectural methodology for organising code as an application grows. Instead of arranging files only by technical type, such as putting all components, hooks, and services together, it combines architectural layers with business-oriented slices and technical segments. The goal is to make a codebase easier to understand and more stable when business requirements change.
The methodology is particularly relevant to applications that have multiple domains, teams, pages, and reusable features. It can be used with different frontend technologies and does not require a particular programming language, UI framework, or state-management library. The official documentation also supports incremental adoption, including use within monorepos.
The important point is that FSD is not simply a folder naming convention. Its value comes from the rules connecting those folders. Layers establish dependency direction, slices represent business meaning, and segments organise code according to technical purpose.
What Is Feature-Sliced Design?
Feature-Sliced Design provides a set of rules and conventions for structuring frontend applications. Its official hierarchy consists of layers, slices, and segments.
The current documented layer structure includes:
| Layer | Main purpose |
| App | Application-wide setup, routing, providers and global styles |
| Processes | Deprecated layer for complex inter-page scenarios |
| Pages | Full pages or substantial route-level sections |
| Widgets | Large self-contained UI or functionality |
| Features | User actions that provide business value |
| Entities | Business concepts such as users or products |
| Shared | Reusable code detached from specific business domains |
Not every project needs every layer. The official documentation specifically advises adding layers only when they provide value.
This makes FSD different from a rigid template. A project can adopt the parts that solve its architectural problems instead of creating empty folders simply to match a diagram.
Layers, Slices and Segments Explained
The three concepts are easier to understand when treated as different questions.
Layers ask: How important is this code to the application’s architecture?
Slices ask: Which business domain does this code belong to?
Segments ask: What technical purpose does this code serve?
For example, a product slice might contain ui, api, and model segments. The UI segment can contain presentation components, the API segment can handle backend communication, and the model segment can contain schemas, stores, or business logic.
The official documentation lists ui, api, model, lib, and config as common segment names while allowing custom segments where appropriate.
This distinction is useful because it prevents developers from creating folders based only on file type. A generic components folder tells a developer what something is, while a purposeful segment such as ui describes why that code exists within its slice.
How Dependency Rules Work
Dependency control is one of the strongest parts of FSD.
A module in a slice can import from lower layers, but it cannot freely import from another slice on the same layer. This creates a predictable direction of dependency and encourages high cohesion with low coupling.
Consider a feature called edit-profile. It can use relevant entities and shared utilities below it. However, it should not directly reach into another feature’s private implementation.
This restriction can initially feel inconvenient. In practice, that friction is intentional. It exposes architectural relationships that might otherwise remain hidden until the project becomes difficult to maintain.
Why Public APIs Matter
FSD also uses public APIs to control access to a slice’s internals.
Instead of allowing another part of the application to import a deeply nested implementation file, a slice exposes selected functionality through a public entry point. The official documentation describes this as a contract between a group of modules and the code consuming them.
| Architectural practice | Result |
| Deep imports into another slice | Strong coupling |
| Public API imports | Clear boundary |
| Same-layer cross-imports | Architectural risk |
| Lower-layer dependency | Predictable structure |
| Business-domain slices | Better code navigation |
A practical benefit appears during refactoring. If internal files move while the public API remains stable, consumers do not necessarily need to change.
Feature-Sliced Design and the Pages-First Approach
A significant development in the methodology was FSD v2.1, announced in November 2024. One of its notable changes was the “pages first” approach. Instead of extracting code into reusable abstractions too early, developers are encouraged to keep code close to the page where it is actually used.
This addresses a common architectural problem: premature abstraction.
If a form is used on only one page, creating a separate feature or entity for it may increase complexity without creating meaningful reuse. The newer approach makes reuse a reason for moving code downward through the architecture rather than treating extraction itself as a virtue.
That is one of the more useful practical lessons from modern FSD: not every piece of code needs to become reusable.
Benefits and Trade-Offs
FSD can improve navigation, dependency control, team coordination, and long-term maintainability. Developers can more quickly determine where business logic belongs because the architecture provides shared conventions.
It also creates useful boundaries for larger teams. A developer working on authentication, for example, can work inside a relevant area without automatically reaching into unrelated domains.
However, there are costs.
| Benefit | Trade-off |
| Clear project structure | More architectural rules |
| Dependency boundaries | Some imports become less convenient |
| Business-oriented organisation | Requires domain understanding |
| Better scalability | Can be excessive for small apps |
| Easier refactoring | Migration requires planning |
The official documentation itself recommends considering whether an existing architecture is actually causing problems before switching. If a project already works effectively, migration may not be worthwhile.
When Should You Use It?
FSD is most compelling when a frontend application has grown beyond a simple collection of pages and components.
Typical warning signs include:
- Developers struggle to locate business logic.
- Features depend heavily on unrelated features.
- Refactoring one area frequently breaks another.
- Multiple developers work on the same codebase.
- Business requirements change frequently.
- The application has several distinct domains.
For a small landing page or simple prototype, adopting every FSD layer may create more ceremony than value.
The better approach is incremental adoption. Start by identifying real architectural problems, then introduce boundaries where they solve those problems.
The Future of Feature-Sliced Design in 2027
By 2027, the main question around FSD is unlikely to be whether every frontend project should use it. The more practical question will be how architectural rules can remain useful while development tools become increasingly automated.
The official FSD ecosystem already includes tooling such as Steiger, an architectural linter, as well as generators and examples. The project also maintains resources designed for AI coding agents, while explicitly cautioning that final architectural decisions should remain with human developers.
That distinction matters. AI tools can generate folders and code quickly, but they can also encourage unnecessary abstraction. FSD’s value in 2027 may therefore come less from manually creating directories and more from using automated checks to preserve meaningful architectural boundaries.
Key Takeaways
- FSD organises frontend applications through layers, slices, and segments.
- Dependency direction is central to the methodology.
- Public APIs prevent other parts of the application from depending on internal implementation details.
- FSD v2.1’s pages-first approach discourages premature extraction.
- Not every application needs every layer.
- Migration makes the most sense when an existing architecture creates measurable problems.
- Automated tooling can help enforce architectural rules, but developers still need to make the structural decisions.
Conclusion
Feature-Sliced Design offers a disciplined way to organise frontend applications around business meaning rather than file type alone. Its layers provide architectural direction, slices group related business concepts, and segments organise implementation by technical purpose.
Its greatest strength is not the folder structure itself. The real benefit comes from boundaries: controlled dependencies, public APIs, and clearer ownership of code. These rules become increasingly useful as applications and development teams grow.
At the same time, FSD should not become architecture for architecture’s sake. The current methodology explicitly allows projects to omit unnecessary layers and supports incremental adoption. Its pages-first approach also recognises that premature abstraction can create unnecessary complexity.
For teams dealing with a genuinely large or interconnected frontend codebase, Feature-Sliced Design provides a practical framework for making complexity easier to manage.
Frequently Asked Questions
What is Feature-Sliced Design?
Feature-Sliced Design is a frontend architectural methodology that organises applications through layers, business-oriented slices, and technical segments.
What are the main FSD layers?
The documented hierarchy includes App, Processes, Pages, Widgets, Features, Entities, and Shared. Processes is deprecated, and projects do not need to use every layer.
What is a slice in FSD?
A slice is a group of code organised around a business domain or product meaning. Examples might include user, post, or comment.
What are segments in Feature-Sliced Design?
Segments organise code by technical purpose. Common examples include ui, api, model, lib, and config.
Is FSD suitable for small projects?
It can be used in projects of different sizes, but the official guidance suggests adopting it when the architecture provides meaningful value. A simple project may not benefit from its full structure.
What changed with FSD v2.1?
FSD v2.1 introduced a pages-first approach that encourages developers to keep single-use code near the page where it is consumed instead of extracting abstractions prematurely.
Methodology
This article was developed from the supplied Postcard.fm editorial brief and current official Feature-Sliced Design documentation. The technical descriptions of layers, slices, segments, dependency rules, public APIs, pages-first architecture, and supporting tooling were checked against official FSD documentation and its maintained GitHub resources.
No firsthand testing or personal development experience is claimed. The article therefore avoids presenting invented testing results or practitioner observations. The supplied editorial brief specifically requires firsthand signals to be genuine rather than fabricated.
References
Feature-Sliced Design. (2026). Overview. Feature-Sliced Design documentation.
Feature-Sliced Design. (2026). Slices and segments. Feature-Sliced Design documentation.
Feature-Sliced Design. (2026). Public API. Feature-Sliced Design documentation.
Feature-Sliced Design. (2026). Layers. Feature-Sliced Design documentation.
Feature-Sliced Design. (2024). v2.1: Pages come first! GitHub Discussions.
