---
title: "SCSS | Skills We Assign For | Azendo"
description: "SCSS on established frontends — managing inherited stylesheets, what native CSS now replaces, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/scss/"
---

[Skills](https://azendo.co/skills/) Frontend frameworks and tooling 

# SCSS.

SCSS is a CSS preprocessor adding variables, nesting, mixins, functions and file partials to standard CSS. It compiles to plain CSS and remains the most common styling layer in established codebases, particularly those predating utility-first frameworks and component-scoped styling.

## Where SCSS fits on a long engagement.

SCSS earned its position by fixing real problems, and native CSS has since absorbed several of them. Custom properties cover most variable use, native nesting is now broadly supported, and container queries handle cases that once needed mixins. A modern SCSS codebase should be shrinking toward the features that still have no native equivalent rather than using all of them out of habit.

The characteristic failure is nesting depth. Deeply nested SCSS compiles to long selector chains that are specific enough to be unoverridable, which is how a stylesheet reaches the state where every new rule needs an escalation to win. Keeping nesting shallow is worth more than any other single convention in an SCSS codebase.

## What an assigned team does with SCSS.

Stylesheets decay in a way that is invisible on any single ticket and obvious across a year. Nobody deletes a rule because nobody can prove it is unused, so the file only grows. Holding that line is a continuity problem rather than a skill problem.

On a standing assignment the stylesheet is somebody's responsibility rather than everybody's, which is what keeps it from becoming append-only. How that ownership is agreed and reviewed is described in [how an assignment runs](https://azendo.co/how-it-works/).

## What we use SCSS for.

* Inherited stylesheets with unclear ownership Establishing what is still used, then reducing nesting depth so changes stop requiring specificity escalation.
* Migrating toward native CSS features Replacing preprocessor variables with custom properties where the runtime behaviour is actually wanted.
* Shared styling across several applications Partials and mixins packaged so more than one product consumes the same source of truth.

## How SCSS capacity is assigned.

SCSS work sits inside frontend capacity under [outsource software development services](https://azendo.co/services/software-development/), usually alongside the design capacity that specifies what it expresses.

## Roles we assign SCSS for

* [Frontend Developer Software development](https://azendo.co/services/software-development/frontend-developer/)

## Service lines it sits in

* [Software development](https://azendo.co/services/software-development/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in frontend frameworks and tooling

* [Vue — skill we assign for](https://azendo.co/skills/vue/)
* [Angular — skill we assign for](https://azendo.co/skills/angular/)
* [Svelte — skill we assign for](https://azendo.co/skills/svelte/)
* [Nuxt — skill we assign for](https://azendo.co/skills/nuxt/)
* [Vite — skill we assign for](https://azendo.co/skills/vite/)
* [Webpack — skill we assign for](https://azendo.co/skills/webpack/)
* [Tailwind CSS — skill we assign for](https://azendo.co/skills/tailwind-css/)
* [Redux — skill we assign for](https://azendo.co/skills/redux/)

## Tell us what your roadmap needs SCSS for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)