CSS Architecture for Small Visual Projects

CSS architecture for large applications gets plenty of attention. Design systems, utility-first frameworks, CSS-in-JS, and scoped styles all address the problem of scaling CSS across large teams and complex component trees. But small visual projects, the kind that make up most front-end gallery work, component experiments, and personal sites, have different constraints and deserve their own architectural approach. This guide covers how to structure CSS for projects with 10 to 50 components, one to three contributors, and a focus on visual quality rather than organizational scale. We address file structure, naming discipline, custom property strategy, specificity management, and the pragmatic compromises that keep small projects maintainable without drowning in process overhead.

Why Small Projects Need Architecture Too

The temptation with small projects is to skip architecture entirely. One big CSS file, write selectors as needed, refactor later. This works for about two weeks. Then you add a new component, realize you named a class that conflicts with an existing one, override something accidentally, and spend an hour debugging a specificity fight that architecture would have prevented.

Small projects do not need the same architecture as large ones. They need a lighter version of the same principles: predictable naming, flat specificity, logical file organization, and a clear path for adding new components without breaking existing ones.

File Structure

For a visual project with 20 to 40 components, this file structure works well:

assets/scss/
  _tokens.scss        (colors, fonts, spacing, radii, shadows)
  _base.scss          (reset, body, typography, links)
  _layout.scss        (page containers, grids, spacing utilities)
  _header.scss        (site header and navigation)
  _footer.scss        (site footer)
  _cards.scss         (all card variants)
  _pages.scss         (page-specific styles)
  _home.scss          (home page specific)
  main.scss           (imports only)

Each file is a logical grouping of related styles. The total number of files stays manageable (under 15), and finding where a style lives is intuitive.

The import file (main.scss) should contain only @use statements, in the order the styles cascade: tokens first, then base, then layout, then components, then page overrides.

Naming Convention

For small projects, a simplified BEM approach provides enough structure without the verbosity of full BEM. Use block-level class names as the primary selector, with element-level classes using a single dash separator:

.card { }
.card-image { }
.card-title { }
.card-body { }
.card-tags { }

For state variations, use a modifier class:

.card.card-featured { }
.card.card-compact { }

This is flatter and more readable than strict BEM (card__image, card--featured) while providing the same collision protection. The key discipline is that every class name starts with its component name, preventing accidental collisions.

Custom Properties

CSS custom properties (variables) are the foundation of a maintainable visual system. Define design tokens as custom properties at the :root level or in a Sass variables file:

$color-canvas: #1a1a1f;
$color-text: #e8e6e1;
$color-accent: #4a7af5;
$space-md: 1rem;
$radius-md: 8px;

Using Sass variables for tokens that are consumed in Sass files (calculations, mixins) and CSS custom properties for tokens that need runtime access (theming, JavaScript interaction) is a practical split.

For component-level custom properties, scope them to the component:

.card {
  --card-padding: 1.5rem;
  --card-radius: 12px;
  padding: var(--card-padding);
  border-radius: var(--card-radius);
}

This makes component customization possible without specificity escalation. A parent context can override --card-padding without touching the component’s internal styles.

Specificity Management

The single most important CSS architecture rule for small projects: keep specificity flat. Every selector should be a single class. No IDs in stylesheets. No element selectors qualified with classes (.card h3). No nesting beyond one level in preprocessors.

When you need to override a style based on context, use a modifier class rather than increasing specificity:

/* Instead of this: */
.home-section .card { padding: 2rem; }

/* Do this: */
.card-home { padding: 2rem; }

Flat specificity means every override is predictable. You never have to count selector weights or use !important to win a specificity fight.

Responsive Approach

For small visual projects, mobile-first with two to three breakpoints is sufficient. Define breakpoints as Sass variables and use them consistently:

$bp-md: 768px;
$bp-lg: 1024px;

.card-grid {
  display: grid;
  grid-template-columns: 1fr;
  gap: 1rem;

  @media (min-width: $bp-md) {
    grid-template-columns: repeat(2, 1fr);
  }

  @media (min-width: $bp-lg) {
    grid-template-columns: repeat(3, 1fr);
  }
}

Co-locate responsive styles with their component rather than in a separate responsive file. When all breakpoint behavior for a component lives in one place, maintenance is straightforward.

When to Refactor

The signal to refactor is when you start duplicating styles across components. If three different card variants share the same padding, border, and shadow, extract those shared properties into a base .card class and build variants on top. If five components use the same spacing pattern, create a spacing utility or extract a layout primitive.

Refactor when patterns emerge, not preemptively. Over-engineering the architecture of a 20-component project wastes more time than it saves.

From CodePen to Production Thinking covers integrating components into production projects
How to Document UI Experiments covers maintaining documentation alongside code
Dashboards demonstrates CSS architecture in component-heavy interfaces