SCSS · Architecture

A 7-1 SCSS Architecture That Survives Multiple Teams

An approach to SCSS architecture based on scope, ownership, dependency direction and blast radius — not just folder names.

Jaymin Maheta 15 Dec 2025 8 min read

Share:

7-1 is a starting point, not the whole answer

The 7-1 pattern — seven folders (abstracts, base, components, layout, pages, themes, vendors) rolled up into one `main.scss` — gives a codebase a shared vocabulary. That's valuable, but it's also where most teams stop, and folders alone don't stop stylesheet sprawl.

What actually keeps a large SCSS codebase healthy over years and multiple contributors is the rules about what's allowed to depend on what, and who owns each layer. The folder structure is just where those rules become visible.

The rules that make it hold

Dependencies flow one direction

Abstracts and base can be imported by anything. Components can import abstracts, never the reverse. Pages can import components, never the reverse. No cycles, ever.

Abstracts hold no output CSS

Variables, functions and mixins only. If a file in `abstracts/` ever compiles to actual CSS, it's in the wrong folder — that's a silent source of duplicated rules.

One component, one file, one owner

Every component file maps to exactly one UI component and one team's responsibility. Shared components live in a clearly separate, explicitly reviewed folder.

Pages compose, they don't define

Page-level SCSS should only handle layout composition — grid, spacing between sections. New colors or component styles in a page file are a sign something belongs one layer down.

Theme layer owns every token override

Light/dark and brand variants live entirely in `themes/`, redefining tokens from `abstracts/`. No other layer is allowed to branch on theme.

Lint the dependency direction

Stylelint's import-order rules catch a component importing a page file, or a rogue cross-team import, before it reaches review — where it's much harder to unwind.

Blast radius is the metric that matters

The real test of a CSS architecture isn't how it looks in the folder tree — it's what happens when someone changes a variable. In a well-scoped 7-1 setup, changing a component's internal spacing touches one file. Changing a design token touches the theme layer and ripples predictably through everything that references it, with no surprises outside that path.

When a "small" style change starts requiring a search across the whole codebase to find every place it might break, that's the architecture telling you a boundary is missing — usually a shared value that should be a token but got hardcoded somewhere instead.

The takeaway

7-1 gives you folders; enforced dependency direction and clear per-layer ownership are what make it survive multiple teams. Lint the import direction, keep abstracts free of output CSS, and push every theme decision into one layer — and a style change stays a one-file change, no matter how large the codebase gets.

Let's talk about your frontend