The hardest part of CSS is not writing it.
It is keeping it consistent over twelve months, three developers, and four redesigns.
Every codebase I have inherited that became unmaintainable did not get there because of bad CSS. It got there because of decisions made in the first week of the project that nobody revisited until the cost was too high to fix.
Here are the decisions that determine whether your CSS stays clean or turns into a tangle nobody wants to touch.
Decision 1: How You Handle Spacing
Spacing is the most-touched part of any design. Margins, padding, gaps, container widths. These get adjusted on every page, in every component.
The codebases that stay maintainable use a spacing scale. Four pixels, eight pixels, twelve pixels, sixteen pixels, twenty-four, thirty-two, forty-eight, sixty-four. Every spacing decision picks from the scale.
The codebases that fall apart use whatever value looks right at the time. Twelve pixels here, fourteen pixels there, eighteen pixels somewhere else. After a year, the codebase has forty different spacing values and no two components feel related.
The reason this matters is consistency at scale. With a scale, a developer can ship a new component without thinking about spacing. They pick from the scale. The result fits. With no scale, every component is a custom decision, and after a hundred components nothing looks the same.
In Tailwind, the spacing scale is built in (the 1, 2, 4, 6, 8, 12, 16 values). In a custom system, you define it once in the design tokens and never use raw values.
The rule is simple. If a designer hands you a Figma file with a five-pixel margin, push back. Five pixels is not on any reasonable scale. Either the design needs four or six, or you need a better scale.
Decision 2: Where Component-Specific Styles Live
There are three common approaches.
Inline utility classes (Tailwind, Open Props, Mantine). All styling is on the element. No separate CSS file per component.
CSS Modules or scoped CSS. Each component has its own CSS file with class names that are scoped to that file. Styles cannot leak.
Global stylesheets with BEM or similar conventions. All CSS lives in a few large files. Naming conventions prevent collisions.
There is no universally right answer. There is a right answer for your team.
If your team has more designers than developers, or if speed of iteration matters more than CSS purity, utility classes are the right call. Tailwind has won the broader market because it is fast to write, fast to read, and the design system lives in the config.
If your team is building a long-lived application with complex components and the same developers will maintain it for years, CSS Modules or scoped CSS is often cleaner. The component file owns its styles. There is no question about where a style is defined.
If you are working in a legacy codebase that already uses BEM or global CSS, sticking with the convention is more important than switching. Mixing approaches is worse than picking the wrong one.
What goes wrong is mixing. A codebase with Tailwind utilities, CSS Modules, global stylesheets, and a few inline styles for "the things Tailwind cannot do" is a codebase nobody can predict. Pick one approach and commit to it.
Decision 3: How You Handle Responsive Design
The naive approach is to add breakpoints everywhere. md:flex, lg:grid-cols-3, xl:text-xl scattered across every component.
This works until it does not. Once the codebase has hundreds of components, the question becomes which breakpoint values to use, where to apply them, and what the design looks like at each step. Without a system, every component answers these questions differently.
The maintainable approach is to have a small number of breakpoints with clear meanings.
Mobile-first by default. The base styles work on the smallest screen. You add responsive variants only when the layout actually needs to change.
Three breakpoints, not seven. A mobile-tablet-desktop breakpoint structure (or a roughly 640px / 1024px split) is enough for most projects. Adding xs, sm, md, lg, xl, 2xl breakpoints means six different versions of every component to think about. Most projects only need two or three.
Container queries when the component cares about its container, not the viewport. A card that needs to switch layouts when it is in a wide column versus a narrow column should respond to its container width, not to the window. Container queries are now well-supported and they make components genuinely portable.
The rule is fewer breakpoints, used more intentionally. Not more breakpoints, used reflexively.
Decision 4: How You Theme
If your site has a single visual style and will never have more, you can hard-code colors and call it done.
If your site has dark mode, white-label theming, accessibility variants, or multiple brands sharing infrastructure, you need a token system from day one.
A token system means colors, typography, spacing, shadows, and other design values live in CSS custom properties or a config file. Every component references the token, not the value.
/* Wrong */
.button { background: #6C63FF; }
/* Right */
.button { background: var(--color-primary); }The cost of starting with tokens is one week. The cost of retrofitting tokens into a year-old codebase is months.
The decision point is not whether you need theming today. It is whether you might need theming in the next eighteen months. If the answer is maybe, start with tokens.
Decision 5: How You Handle Animation
Animation is where CSS gets messy fastest.
The codebases that stay clean treat animation as a system. There is a set of standard durations (one hundred fifty milliseconds, two hundred fifty, four hundred). There is a set of standard easings (ease-out, ease-in-out, custom cubic-bezier for branded animations). Every animation picks from the system.
The codebases that fall apart let every component define its own animation. After a year, the site has fifty different durations, twenty different easings, and no two transitions feel related. The site feels janky even though every individual animation is fine.
The fix is the same as for spacing. Define the scale once. Use it everywhere. Reject custom values unless there is a real reason.
For complex animations (page transitions, sequenced reveals, scroll-triggered effects), pick one library and use it everywhere. Framer Motion, GSAP, or native CSS. Mixing libraries means competing animation systems, and competing systems fight each other.
Decision 6: How You Handle State on Elements
A button is rarely just a button. It has hover, focus, active, disabled, loading, and sometimes selected states.
The codebases that stay maintainable handle state through a clear pattern. Every interactive element has the same set of states defined the same way. Hover always works the same. Focus always uses the same outline. Disabled always reduces opacity by the same amount.
The codebases that fall apart let each component invent its own state pattern. One button uses opacity for disabled. Another uses a gray background. A third uses cursor: not-allowed and nothing else. After a year, no two interactive elements feel the same.
The fix is to define interaction states at the design system level, not the component level. Every component imports the same states. Every state is implemented the same way.
In Tailwind, this looks like a set of consistent state classes (hover:bg-primary-dark, focus:ring-2, disabled:opacity-50). In a custom system, it is a mixin or shared file.
The Common Thread
Every decision above is the same decision in different clothing.
Define the system once. Use it consistently. Reject one-off values that do not fit.
The CSS codebases that stay clean are not the ones with the cleverest tricks. They are the ones with the strictest discipline about consistency.
The reason this is hard is because the cost of breaking the system is invisible at first. Adding one custom value does not break anything. Adding fifty custom values over a year creates a codebase nobody can maintain.
The fix is to set up the system early, document it, and reject any change that does not fit. Boring? Yes. The kind of CSS that lasts? Also yes.
If you are starting a new project, spend the first day on these decisions. The compounding cost of getting them wrong is much higher than the cost of getting them right.
If you are inheriting a project that already has problems, fix one decision at a time. Start with spacing. Then tokens. Then animation. Each fix makes the next one easier.
The goal is a codebase that is still pleasant to work in twelve months from now. Every decision above is in service of that goal.