Dark Mode: Worth Building, or a Distraction From What Matters?

I get asked about dark mode more often than almost any other feature request. Someone on the team saw it in Slack or Linear, liked it, and now it's on the list for the internal tool I'm building them. It sounds like a small ask. In practice, doing it properly is one of the more fiddly bits of front-end work you can take on, and doing it badly is worse than not having it at all.

So before it goes on a spec, it's worth asking what problem it actually solves for this particular piece of software, and whether that problem is worth the build time.

Why it's not a five-minute toggle

Flipping a background from white to black is the easy 20%. The other 80% is everything that touches colour indirectly:

• Charts, graphs and status badges that were designed against a white background and now look washed out or unreadable on dark
• Icons and logos with baked-in colours or transparent PNGs that assumed a light backdrop
• Text contrast ratios that need checking again in both modes, not just the one you designed first
• Third-party embeds (calendars, PDF viewers, payment widgets) that don't respect your theme at all
• Screenshots in help docs and onboarding that now only match one of the two modes

If you're building on a component library with proper design tokens, a lot of this is manageable. If the styling has grown organically over a couple of years, with colours hardcoded in dozens of places, adding a second theme means touching most of the codebase, not adding a switch.

Who's actually asking for it

It's worth separating two very different requests that sound the same.

The first is a genuine need: someone using a dashboard for six hours a day, in a dim office or at night, who finds a bright white screen tiring on the eyes. That's a real, evidence-backed reason. Long screen time in low light is exactly the case dark mode was designed for.

The second is preference dressed up as a need: "it looks more modern" or "our competitor has it". That's not nothing, a polished-looking product does help perception, but it's a different kind of value and it should be weighed against other things that also make a product look considered: consistent spacing, sensible empty states, fast page loads, forms that don't lose your data on a refresh.

Internal tools are a different case to customer-facing SaaS

For a system three or four people in the office use between 9 and 5, on a monitor, in a lit room, dark mode is solving a problem that mostly doesn't exist. The time spent building and maintaining two themes is time not spent on the workflow itself, the validation rules, the reports people actually chase you for. I'd rather put that budget into the parts of the system that save someone an hour of admin a week than a theme toggle three people might use once out of curiosity.

For customer-facing SaaS, especially anything used for extended sessions (developer tools, analytics dashboards, writing or editing tools), it's a more defensible ask. Users compare you to the other tabs they have open, and if every other tool in their stack has dark mode, its absence stands out. It's also a feature people notice and mention, which matters if word of mouth matters to your growth.

The cheap version is the risky version

The corner-cutting version of dark mode is a single CSS filter or a naive colour inversion applied over the whole app. It works for about ten minutes until someone hits a chart, an uploaded logo, or a modal with a white background image, and suddenly half the screen is unreadable. I've inherited systems where "we added dark mode" meant exactly this, and untangling it later, once colours are hardcoded everywhere instead of driven by a proper token system, takes longer than building it right the first time would have.

Doing it properly means defining your colours as variables from the start (background, surface, text, border, accent, all named by role rather than by hex value) and building every component against those variables rather than fixed colours. That's a sensible practice even if you never ship a second theme, because it also makes rebranding, white-labelling, or tightening up accessibility contrast far easier down the line.

A rough way to decide

Before adding it to a brief, I'd ask three questions:

• Will people realistically use this for long, unbroken stretches, or in short bursts throughout the day?
• Is the request coming from actual user complaints, or from a screenshot someone liked?
• Is the current design system built on proper tokens already, or would this mean retrofitting colour logic across the whole app?

If the answer leans towards "short bursts, aesthetic preference, no token system yet", I'll usually suggest spending that time elsewhere first and revisiting dark mode once the core workflow is solid. If it leans the other way, particularly for a product people stare at for hours, it's a reasonable investment, just not a quick one.

Either way, it's the kind of decision worth having in a proper brief rather than a single line item, because the cost difference between "add dark mode" and "add dark mode properly, everywhere" is enormous, and only one of those is worth paying for. If you're scoping a build like this, my software brief generator is a quick way to get the detail down before anyone quotes on it.