I do not know what share of my readers use dark mode, and that is exactly the problem — building only in light mode means I have never seen what an unknown number of them see. Both themes get a signed verdict or the surface does not ship.
I do not know how many of the people who will ever look at anything I ship have their system set to dark mode, and I have never had a good way to find out. What I do know is that I build and test in light mode by default, because that is the mode my editor opens in and the mode I do not have to think about. That mismatch is not a small thing. It means I do not know how many readers will see a version of the page I have never reviewed, and I have shipped surfaces that were fine in light mode and quietly broken in dark — text that goes invisible against its own background, a border that vanishes because it was defined as a light grey with no dark counterpart, an icon drawn in a colour that only exists on a white canvas.
The reason this keeps happening is that dark mode gets treated as a feature you add once the "real" version is done, rather than a second rendering of the same surface that has to pass the same bar. Treating it as an afterthought is exactly backwards, because a theme is not cosmetic — it changes which colour tokens resolve, and a design that only defines its palette inside a light-mode block, with nothing defined on the bare root, silently inherits the wrong colours the moment the viewer’s system preference differs from whatever you happened to be looking at while you built it.
So I hold every visual change to a rule: light and dark both get a signed verdict, specifically, or the surface does not ship. Not "it should be fine because we used CSS variables" — an actual screenshot in each mode, checked, with contrast measured in both, because a contrast ratio that passes on a white background can fail completely once the background and text swap towards their dark equivalents. A component that has never been looked at in dark mode has not actually been tested, it has been tested once and assumed twice.
The practical fix is defining the palette the right way round rather than patching it after the fact: a complete light palette as the default tokens, then dark values layered on top only inside the appropriate media query or explicit theme attribute, never a colour whose only definition lives inside a dark-mode block with nothing to fall back to. Get the layering backwards and you end up with a page that borrows whatever background the surrounding chrome happens to be using, which looks like a bug that comes and goes depending on where the page is embedded, and is genuinely hard to reproduce because it depends on context nobody thought to vary.
What convinced me this needed to be a hard gate rather than a preference was how invisible the failures are to the person who introduced them. If you build in light mode and review in light mode, a dark-mode text colour bug produces zero signal in your own workflow — everything you looked at worked, every screenshot you took confirmed it, and nothing in your own process ever asked the question that would have caught it. The bug only exists for the reader whose system you never matched, and by the time it surfaces it is usually a complaint rather than a caught defect, which is a much more expensive way to find out.
Treating dark mode as equal in weight to light mode, checked every time rather than assumed, is a small discipline that removes an entire category of ship-then-apologise bugs. It costs one more screenshot and one more contrast check per surface. Skipping it costs a surface that an unknown number of your readers experience as broken while you experience it as finished.