CSS architecture
Nobody has a CSS problem. They have a stylesheet nobody is willing to change, a design that only works with the content in the mockup, or two teams styling the same button differently.
01Overview
What sits behind a stylesheet, and what does not
CSS is the language browsers use to lay out and style the elements HTML describes. Modern CSS is a different tool from the one most stylesheets were written against: grid and flexbox for layout, custom properties for theming, container queries, and cascade layers for deciding which rules win. It is not a framework, which is what Bootstrap and Material UI are.
02Capabilities
Three jobs, and only one looks like writing rules
Where styling work actually goes on a project. Two of the three are questions about ownership rather than about syntax, which is why they outlast whichever tool is fashionable.
- Layout
Layout that survives real content
Grid and flexbox with container queries, built against long names, missing images and eleven-item menus rather than against the comp. Most layout bugs reported after launch are content the design never considered.
- Tokens
Tokens and theming
Custom properties as the contract between design and code, so colour, spacing and type scale have one definition rather than one per component. This is where CSS meets design systems and UX design, including multi-tenant products where every customer gets its own theme, as in the hospitality platforms we build.
- Cleanup
A stylesheet nobody dares change
Specificity wars, dead rules, overrides of overrides, and a file where nobody can predict what a change breaks. We measure before rewriting: what is actually loaded, what is actually matched, and which rules the product depends on.
03Fit
Where the fear of changing a stylesheet comes from
The styling approach matters far less than where the decisions live and who is allowed to change them. Each of the seven rows below names the decision underneath it, and two of them are about writing styles.
| What you have | What that actually calls for |
|---|---|
| A small site, one or two developers, and a design that rarely changes | Plain modern CSSA naming convention and nothing else. A system here is overhead with no payer, and the convention will outlive whichever tool is fashionable this year. |
| Several teams building against one shared set of components | Different pageA design system, owned as a product. The tokens and the component library have to be one artifact rather than two that drift apart. |
| An internal admin screen where speed to a usable page is what matters | Different pageTake a framework's defaults. Bootstrap beats hand-written styles here, and nobody is judging an operations console on its typography. |
| A distinct brand with several themes, or white-label customers | Custom propertiesOne definition per colour, space and type step, not one per component. Overriding a framework's opinions into your brand costs more than writing the styles would have. |
| A stylesheet nobody can safely edit | Layer, then retirePut new work in a cascade layer the old file cannot outrank, then retire the old rules one surface at a time. A rewrite here stalls and leaves you running both. |
| A design handoff with no token names and no spacing scale | Start upstreamFix that in the design tool first, see Figma. Inventing the scale in code means engineering makes visual decisions nobody asked it to make. |
| The complaint is that a control cannot be used with a keyboard | Fix the elementThat is element choice rather than appearance, and it lives on our HTML semantics page. The fix is inside the component, not in the stylesheet. |
Scope
What we own on styling work is where the decisions live and who is allowed to change them, not the syntax. unicrew has been building browser interfaces since 2012, with 100+ senior in-house engineers across six countries. Our information security is certified to ISO 27001:2022. When a smaller piece of work than the one you came for fixes the stylesheet, that is the piece we propose. Where the whole front end needs an owner rather than a cleanup, that is front-end development.
04Stack
What the styling layer touches
Five neighbours this page keeps pointing at, each with a page of its own if that is the decision you are actually making.
05Questions
What teams ask before they let anyone near the stylesheet
The five that come up most often on a first call, answered the way we would answer them out loud.
Whatever the team that will maintain it can maintain, and where you already have a standard we work inside it rather than adding a second one. The decision we care about is not the syntax. It is where tokens live and who is allowed to add one. Two styling systems in one repository, usually because a new team arrived with a preference, is the expensive version of this question.
Yes, and they are separate pieces of work worth keeping separate. A cleanup is measurable: less shipped CSS, fewer overrides, predictable components, and no visual change a user notices. A redesign changes what the product looks like and needs design involvement. Mixing the two makes it impossible to tell whether a regression came from the cleanup or from the new look.
Design owns the names and the values. Engineering owns how they reach the browser, and stops anything bypassing them. When engineering invents the names, the design tool and the product drift apart within months. When design hands over colour codes with no scale, engineering ends up making visual decisions in a pull request. Our design systems work exists to close that gap.
Cheap if tokens were there from the start, expensive if colours were written literally into components. The work in retrofitting a theme is almost never the theme. It is finding every hard-coded value and deciding what it should have referred to. If a second theme is even possible in your future, define the tokens now. It is one of the few front-end decisions where the early version costs nothing extra.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we only offer it once the first read is done, because a fixed number on a stylesheet nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer, quoted on the seniority mix the work needs.
Afraid to touch your own stylesheet?
Point us at the front end and tell us what nobody wants to change. You will get an engineer's read on whether the fix sits in your tokens, in rules that keep overriding each other, or in the design handoff. We will also say where web development work would start.