CSS Frameworks for Prototyping: Selection Criteria That Prevent Technical Debt

The prototype shipped on Friday. By Monday morning the production repo held a CSS file nobody had opened since the demo. That is the moment a prototyping stylesheet becomes technical debt: not when you choose it, but when you ship it without a plan for what gets discarded. The selection criteria that matter are shipped cost, byte weight, the build step, and the extraction path that decides whether your prototype is a sketch or a mortgage.

Before 2016, the standard move was to drop Bootstrap's full CSS file into every new project and call it a day. That delivered a working UI in an afternoon and a payload of unused component styles in perpetuity. The tools that replaced it, Tailwind CSS v4.x, UnoCSS, Open Props, and Pico.css, each solve a different part of the problem. Each has a different answer to the question: when the prototype is done, what does it cost to leave?

Measure The Compressed Payload, Not The Demo

Judge a prototyping library by what it emits, not by its landing page. The marketing copy talks about developer experience and iteration speed. The real number is the compressed CSS that reaches the browser. For a single-page prototype, that number ranges from under 1 KB for a classless stylesheet to over 100 KB for a component library with all its resets and utilities included. Gzip rewards repetition, which is why utility classes compress well despite verbose source. Compression does not excuse shipping styles you never use.

The honest metric is shipped bytes after gzip, measured on the actual page, not the library's demo. Tailwind CSS v4.x with its Just-in-Time compiler produces only the classes present in your source files. A typical single-page prototype lands under 10 KB compressed. Pico.css, being classless, ships a fixed stylesheet of roughly 8 KB that styles semantic HTML elements directly. No classes to purge because there are none. Open Props ships zero CSS by default. It exports only custom properties like --size-fluid-3 and --gray-5, and you write the rules that consume them.

Minimal Setup, Real Costs

Here is a minimal Open Props setup, with the reset and a single rule that uses two design tokens:

@import "https://unpkg.com/open-props";

.card {
  padding: var(--size-fluid-3);
  background: var(--gray-5);
  border-radius: var(--radius-3);
}

That rule is three declarations. The only cost is the custom properties you actually referenced. Compare that to a Bootstrap-era prototype where the entire grid system, all button variants, and every form style shipped whether the page used them or not. The difference is not aesthetic. It is the difference between a build that takes 40 ms and one that chokes a mid-range phone.

Pico.css: Zero Classes, One Look

The lightweight tools worth your time make a small payload the default path. Pico.css styles bare HTML elements, <h1>, <p>, <button>, <form>, with no classes required. The prototype looks finished with zero author CSS and the entire file stays under 10 KB uncompressed. The cost is control: every Pico.css page looks like a Pico.css page. Overriding its defaults means writing CSS that competes with its specificity.

Open Props: Tokens, No Opinions

Open Props is the other end of the lightweight spectrum. It ships no classes at all, only custom properties. You write semantic HTML and your own rules, pulling design tokens as needed. The prototype is as light as your CSS discipline allows. The migration path is trivial because you are already writing production-quality rules. You swap the token references for your design system's values.

UnoCSS: On-Demand With An Escape Hatch

UnoCSS fits between them. It scans your source files and generates CSS on demand for the utility classes it finds, with presets compatible with Tailwind CSS and Windi CSS syntax. Its distinguishing feature is the absence of a parsing step. It reads the strings in your class attributes and emits exactly those declarations. A prototype built with UnoCSS and the attributify mode can ship under 5 KB compressed. Because the output is standard CSS, extracting it into a production stylesheet means keeping the generated file.

Prototyping without lock-in is less about the library you pick and more about the test you run before you commit. The test is straightforward: can you take the finished prototype, copy the relevant CSS into a new file, and delete the library's import without rewriting every rule? If the answer requires a build step, a purge pass, or a migration script, you have lock-in.

Tailwind CSS v4.x fails this test by design. Its utility classes are shorthand for declarations. The JIT compiler generates them at build time. When you move to production, you either keep the Tailwind build pipeline or you rewrite every class="grid grid-cols-3 gap-4" as display: grid; grid-template-columns: repeat(3, 1fr); gap: 1rem;. That is not extraction. That is porting.

Here is the utility-to-declaration mapping that makes the porting cost visible:

/* Tailwind v4.x: class="grid grid-cols-3 gap-4" */
.grid { display: grid; }
.grid-cols-3 { grid-template-columns: repeat(3, minmax(0, 1fr)); }
.gap-4 { gap: 1rem; }

Three classes, three declarations. The extraction is a search-and-replace job across every file. The alternative, classless CSS like Pico.css or token-only output like Open Props, keeps your author CSS in plain rules that move to production unchanged. The trade-off is authoring speed. Utility classes are faster to write in the moment. Semantic rules take longer to compose. That is the real decision, and it is a trade-off, not a free lunch.

Why Semantic HTML Wins The First Hour

Classless CSS works because semantic HTML already carries meaning. A <button> is a button. A <table> is a table. A classless stylesheet styles them without asking you to invent names. Pico.css is the reference implementation: it ships resets, typography, forms, and components as element selectors. The prototype looks professional with zero author CSS.

Override Without A Specificity War

The failure case is the override. When you need a button that is not the default Pico button, you write a class or an ID, and now you are fighting specificity. Pico's element selectors sit at a low specificity level, one type selector, (0,0,1), so a single class wins easily. But the cascade layers matter here. Pico's resets and component styles belong to an unlayered origin by default. Your overrides need to come after the stylesheet import in source order.

Here is the override pattern that works, using a class and a custom property to adjust the primary button:

@import "https://unpkg.com/@picocss/pico@2/css/pico.min.css";

.cta-button {
  --pico-primary-background: #c92a2a;
  --pico-primary-border: #c92a2a;
  padding: var(--pico-padding);
}

The custom properties are Pico's design tokens. Overriding them is the supported path. Classless libraries are the best answer for prototypes that must look decent without any author CSS. The migration to production means keeping the stylesheet or replacing it with your own element styles. The cost is uniformity. Every Pico page has the same bones.

Road One: Keep The Build Step

A migration strategy has exactly three roads. The one you take is determined by the library you chose. Road one: keep the tooling in production. Tailwind CSS and UnoCSS are viable in production because their JIT output is small and the utility syntax is maintainable at scale. The cost is the build step. The risk is dead code elimination. If you stop using a class, the JIT drops it. If you generate classes dynamically from JavaScript, the scanner may miss them and ship unused CSS.

Road Two: Extract And Discard

Road two: extract and discard. This works for Open Props and classless libraries. You copy the rules that matter into your own stylesheet, delete the import, and keep the custom properties as your design tokens. The migration is hours, not days, because the prototype CSS was already plain rules.

Road Three: Rewrite

Road three: rewrite. This is the Bootstrap 2014 path, and it is the one that turns a prototype into technical debt. The component classes carry markup structure with them. class="btn btn-primary" is tied to Bootstrap's specific button reset. Removing the library means rewriting the markup and the CSS together. If you started with a component library, you are rewriting.

Here is the migration decision in concrete terms, comparing what ships and what it costs to leave:

Framework	Ships	Build step	Migration cost
Tailwind v4.x	Used utilities only, <10 KB typical	Yes, JIT required	Medium: keep build or rewrite classes
UnoCSS	Used utilities only, <5 KB typical	Yes, on-demand scan	Medium: keep build or rewrite classes
Open Props	Custom properties only, 0 KB base	No	Low: copy rules, keep tokens
Pico.css	Element styles, ~8 KB	No	Low: keep or replace stylesheet

The table is the strategy. If you cannot tolerate a build step in production, Open Props and Pico.css are your only honest choices. If a build step is fine and you want maximum authoring speed, Tailwind or UnoCSS will serve you. Plan to keep the build step forever. The extraction cost is the lock-in.

Declare The Order Upfront

When a prototype grows past its first page, you will write overrides. Those overrides need a predictable place in the cascade. The @layer rule gives you that place explicitly. Instead of hoping your author CSS beats the library's by source order or specificity, you declare the priority order upfront. A library's resets and base styles go into one layer. Your prototype overrides go into another. The later layer wins regardless of specificity.

Here is the layered setup that keeps prototype overrides predictable:

@layer reset, framework, prototype;

@import "https://unpkg.com/@picocss/pico@2/css/pico.min.css" layer(framework);

@layer prototype {
  .card {
    border: 1px solid var(--gray-5);
  }
}

The @layer statement declares the order. The import assigns the library's styles to its layer. Any rule in the prototype layer beats any rule in the framework layer, even if the library selector is more specific. This is the safety net that makes mixing a prototyping stylesheet with your own CSS safe. Without it, you are at the mercy of source order and specificity math.

The Silent Failure You Must Avoid

The failure case comes when the @layer statement is missing and you import the library after your own styles. Then the library's unlayered styles win. Your overrides silently fail. The fix is always the same: declare the layers before any import, and put your author styles in a named layer. This is not optional discipline. It is the difference between a prototype you can extend and one you must rewrite.

What is the single cheapest way to prototype a page today? Open Props with a hand-written stylesheet. It ships zero CSS by default. The custom properties are your design tokens. The migration to production is copying the rules you wrote. The cost is authoring speed: you write every declaration yourself.

When does a prototyping library become technical debt? The moment you ship it to production without a purge step or a migration plan. If the library's CSS file is in your production bundle and you are not using a JIT compiler, you are paying for styles that are dead code. The fix is dead code elimination via a build step or choosing a classless library.

Can I mix two prototyping libraries in one prototype? No. If both define a utility class like .card with different values, the cascade decides the winner by source order. The result is nondeterministic. Pick one library and override its tokens with custom properties. Mixing libraries is how prototypes become debugging sessions.

What do I do at 1 AM when the prototype must ship and the build step is broken? Delete the library import and write plain CSS for the ten elements on the page. A page with semantic HTML and your own rules will always render. A page that depends on a broken JIT compiler will not. Keep a classless fallback stylesheet in your repo for exactly this moment.

Match The Tool To The Trip

The prototyping library you choose should match the trip you are taking, not the one you wish you were on. If you write CSS daily and need a working UI in an afternoon, Tailwind CSS v4.x or UnoCSS will get you there fastest. You already know how to run a build step. The lock-in is a cost you can carry. If you are a full-stack engineer who touches CSS occasionally and cannot afford to debug a JIT failure at 11 PM, Pico.css or Open Props is the reliable choice: no build step, no purge, no surprises.

Who Should Skip The Library Entirely

The design-system author should avoid every prototyping library and write plain CSS with design tokens as custom properties. The prototype is the system. The library would only obscure it. The performance-conscious developer should measure shipped bytes on the actual page and choose whichever option lands under 10 KB compressed. That number, not the marketing, is the truth. The technical writer or educator should use classless CSS for examples. The element selectors teach the semantics that utility classes hide.

Who should not carry a library at all? The developer whose production codebase is a long-lived application with no build step. For that person, any utility-class tool is a forced migration. Any component library is a rewrite. The honest answer is to write the CSS by hand, use Open Props for the tokens, and skip the library entirely. The prototype will take a day longer. You will never spend a weekend unpicking someone else's utility classes.