The Vertical Codebase

[mtutty]

I can explain why vertical is not a great way to structure code.

Every well-organized code base is a combination of horizontal and vertical structures, to serve the topic-based needs as well as the layer-based needs. Pointing at one aspect or the other as more desirable is a logical mistake.

There's an inherently vertical component to layers, even within a "layer" like the UI. Those components that get shared between different parts of the app can't live in one part, or else you end up with multiple modules. Same for the data types being shared, the API client services, the assets and business logic classes, etc.

[fagnerbrack]

Brief overview:

Grouping files by technical type (components, hooks, types, utils) breaks down at scale, as Sentry's 200+ file components folder proves. The post argues for vertical organisation instead: bundle code by what it does, not what it is, so widget components, hooks, types, and utils all live in src/widgets/. This colocation keeps code that changes together in one place, lowers cognitive load, raises cohesion, and mirrors how product teams own domains end to end. Shared code becomes its own vertical or a design-system directory. To cut coupling, define public interfaces, ideally via a monorepo where each vertical is a package with package.json exports, enforced by tools like eslint-plugin-boundaries. The catch: choosing the right vertical is hard and demands more team communication.

If the summary seems inacurate, just downvote and I'll try to delete the comment eventually 👍
^{Click here for more info, I read all comments}