“Shall we add dark mode?” usually turns into an argument about taste. It is not a matter of taste, though — it is a question of whether to double what you maintain, and framed that way the decision gets much easier. Here is the honest case on both sides.
What actually doubles
Dark mode starts as inverting some colours and does not end there. You acquire a second complete set of screens that must be verified.
The most commonly overlooked item is contrast. A colour pairing that passes on a light background offers no guarantee at all on a dark one. When the brand colour is a saturated mid-tone in particular, contrast that was comfortable against white frequently falls short against near-black. Both sets need checking separately.
Then there are images. Charts and logos exported on a white background punch bright rectangles into a dark page. On a documentation site full of screenshots you either maintain two sets of captures or accept light-mode screenshots embedded in dark pages.
When it is nonetheless worth doing
None of which means do not do it. There are cases with a clear reason behind them.
The dividing line is dwell time. On a site where people stare at the screen for minutes at a stretch, a dark background is a real comfort. On a brochure site where a visitor spends thirty seconds and then presses the enquiry button, you gain very little and take on a whole second surface to keep correct.
If you are building it, start with tokens
Implementation succeeds or fails on where the colours are written down. In a codebase where every component hard-codes its own values, adding dark mode means hunting through hundreds of places and bolting conditions onto each. Where colour is expressed as semantic tokens — surface, ink, border, accent — you write one extra set of values and you are done.
It is also easy to forget there are three states, not two: the user chose light, the user chose dark, and the user chose nothing and follows the operating system. The third is the default, so arrange things such that system preference and an explicit choice do not overwrite each other.
Having drawn your illustrations as code pays off handsomely here. Their colours come from tokens, so they follow the mode switch on their own and not a single drawing has to be remade.
If you are not building it, be deliberate about that too
Deciding against dark mode leaves one job: make the unsupported state properly defined. Declare background and text colours explicitly and the page looks as intended everywhere. Leave them undeclared and some browsers or extensions will invert colours on their own, producing exactly the half-dark screen you decided not to have.
And the decision is reversible. Get the token structure right now and dark mode later becomes adding one set of values. Deferring the decision and deferring the preparation are different things.
Designing that token structure from the start is covered in the design tokens series, and how theme and plugin choices affect maintenance cost lives in the themes and plugins archive. If you would like decisions like this reviewed while an existing site is tidied up, see our optimization program.