We want to add dark mode to our site. What does it actually take, and do we need it?

Picking dark colours takes an afternoon. The work is everywhere else: every hex value typed straight into a component, every screenshot exported on a white background, and every shadow that quietly stops working when the page behind it is near black.

Here is the difference in one line of code. A page background set to--grey-100cannot flip, because nothing in that name recorded what the colour was for. A page background set to--surfacecan flip, because the name describes a job and the value can change underneath it. Renaming shade tokens to role tokens is the project. The dark palette is the easy part at the end.

Teams often discover this the moment they ask for a toggle. They thought they had a design system. What they had was a paint chart with a build step.

In our projects, none of the three are the palette.

Literal token names come first. If your tokens are--blue-500,--grey-900and--white, every component using them has to be read and reassigned to a role: surface, surface raised, border, text primary, text muted, accent. That touch list is your whole component library.

Assets come second, and they are usually more work than the CSS. Logos with white boxes baked in, product screenshots taken in light mode, illustrations with opaque backgrounds, PDFs and social cards. A site with forty images will need a decision on each of the forty.

Depth comes third, and it is where retrofits look wrong rather than broken. Light mode lifts a card off the page with a soft shadow. On a near-black background there is no shadow to speak of, because a dark blur on a dark surface is invisible. Hierarchy has to be rebuilt with surface lightness instead: the page at one level, the card a step lighter, a popover a step lighter again. Skip that step and every dark-mode card looks like it is lying flat on the floor.

Three smaller things need reinventing too. Focus rings that read on white often disappear on charcoal. Disabled states built by lowering opacity go from grey to nearly gone. And brand accents that pass contrast against white frequently fail against near black, so the accent gets a second, lighter value that only exists in dark mode.

Run these five checks in order. The first four cost nothing but an afternoon, and they usually settle the question before anyone writes a quote.

Step five matters most. A homepage is mostly hero, heading and whitespace, so it looks fine in dark mode almost by accident. A pricing table with borders, badges, a highlighted plan and a comparison grid is where the surface levels either work or fall apart.

1. Search the codebase for `#` hex values and `rgb(`. Every result outside the token file is a line item someone has to fix by hand.
2. Read your token names aloud. Any name describing the colour rather than the job has to be renamed before dark mode starts, and that rename touches every component that uses it.
3. Count the assets with baked-in backgrounds. For each one decide: transparent version, separate dark variant, or a thin border and leave it light.
4. Pick the scope honestly. Respecting the operating system preference is far cheaper than a visible toggle, because a toggle needs stored preference, server-side handling to avoid a flash of the wrong theme on first paint, and a support surface when it goes wrong.
5. Build one hard page in both themes before committing to the rest. Pricing table or a dense dashboard, never the homepage.

Marketing sites with short sessions get close to nothing from dark mode. Nobody is reading your pricing page at midnight with the lights off. If your median session is ninety seconds, you are paying for a preference the visitor never has time to form.

The real cases are things people stare at for hours: developer tools, dashboards, editors, anything read at length. If demand for dark mode is coming from your logged-in users, ship it in the product and leave the marketing site alone. That is a smaller job with all of the payoff.

Two cheaper fixes usually solve the underlying complaint. First, fix contrast in light mode, because much of what reads as “too bright” is actually thin grey text on pure white. Second, back off pure white itself. Moving a page background from#FFFFFFto something around#FAFAFAremoves most of the glare people are objecting to and costs one token change.

One warning worth acting on. If a studio quotes dark mode as a small extra at the end of a redesign, they have not opened your asset library. Ask them how many of your images have white backgrounds. If they cannot answer, the number is not in the quote.

Name colours by role instead of by shade.--surface,--surface-raised,--border,--text-muted,--accent, not--grey-50and--blue-600.

That single change turns dark mode from a project into about a week of work, because the only thing left is choosing values. It also pays off with no dark mode at all: role names tell the next developer where a colour belongs, which is why sites drift into eleven slightly different greys in the first place.

So the honest answer to the original question is two answers. You probably do not need dark mode on a marketing site. You do need a colour system with meaning attached, and that is the part of the work you were about to pay for anyway.