The fastest way to ship dark mode is a CSS filter that inverts every colour on the page, and it produces a genuinely unpleasant result: images invert into unnatural colours, shadows that should recede now appear to glow, and a white card floating on a previously-white background becomes a dark card with none of the visual hierarchy the light version had. Users notice this immediately even if they can't articulate why the dark mode feels wrong.
Proper dark mode is a separate colour palette, designed deliberately rather than derived mechanically, using design tokens so the two themes can be swapped without duplicating every component. This is where the design system work covered in the piece on component libraries actually pays for itself — a token-based palette where colours are named by role (surface, border, muted-text) rather than by literal value makes adding a second theme a matter of defining new token values, not rewriting every component.
Contrast needs re-checking, not assumed to carry over. A colour pairing that meets accessibility contrast requirements in light mode does not automatically meet them once the background flips to dark — text that was comfortably readable against white can become genuinely hard to read against a near-black background at the same relative lightness, and this needs verifying with an actual contrast checker rather than eyeballed.
Images and icons need their own treatment rather than being left to invert. A logo or illustration designed for a light background often needs a dedicated dark-mode variant, because simply darkening the surrounding page while leaving a light-background image untouched produces a visible box around it that looks like a bug rather than a design choice. Budgeting for these variants at the point of adding dark mode, rather than discovering the gaps one screenshot at a time after launch, is what separates a dark mode that feels designed from one that feels bolted on.
