A SaaS client we redesigned for last September shipped with a dark-mode default. The Figma mocks were beautiful. The marketing screenshots were better. Three months later, the Hotjar replays told a different story. The bulk of their power users — the people logged in eight hours a day pulling reports — were toggling to light mode within the first session and never going back. The session-recording numbers were almost embarrassing. About 71% of accounts that touched the theme switcher landed on light and stayed there.
We redesigned again. Light-first. The dark toggle is still there, buried in settings, and roughly nobody finds it.
Why dark mode photographs better than it works
Dark UI is genuinely beautiful in screenshots. White-on-near-black at low information density looks like a luxury car interior. Your charts look like a Bloomberg terminal. Your typography looks intentional. None of this is a lie. It's just that the conditions that make dark mode look good in a marketing render are the conditions that almost never exist in real B2B usage.
Real B2B usage is: a tab open for nine hours, ambient fluorescent office light, a tired person comparing two numbers in a table to a third number in an invoice PDF that opened in another tab. The PDF is white. The invoice email is white. The spreadsheet they exported to is white. The dark UI is the one outlier in a workflow that is otherwise blindingly bright, and the eye has to re-adapt every time the user switches contexts. That re-adaptation is the fatigue. It is not abstract. It is a real cost.
Charts get worse
This is the part nobody on the marketing team wants to hear. Data visualization on dark backgrounds is harder. Not impossible — done well it can be excellent — but the cost is real and most teams don't pay it.
The problem is that on a light background, you have a near-infinite palette of saturated colors that read clearly against white. On dark you don't. Saturated colors on dark either glow (which exhausts the eye over time) or get pulled toward the background (which kills contrast). Your sequential color ramps need to be redesigned. Your divergent palettes need to be redesigned. Your single-hue ramps for treemaps need to be redesigned. We have watched analytics teams ship dark dashboards where two adjacent shades of blue were genuinely indistinguishable on a mid-tier office monitor.
The other problem is gridlines. On a white background you can drop a 5% gray gridline and it disappears unless you look for it. On dark you cannot. You either ship a gridline that is too prominent, or you ship one that is invisible. There is no equivalent of "barely there" in dark territory.
Sustained reading
The research on long-form reading is mixed but tilts toward light-on-dark being harder for people with normal vision in normal lighting. People with astigmatism in particular report halation around text on dark backgrounds — letters smearing, edges fuzzing. This isn't a small population. It's roughly a third of adults. We have had user-test participants struggle to read paragraph copy on dark backgrounds and not be able to tell us why; the why was that their eyes weren't tracking cleanly.
For an app that's all interactive UI, this matters less. For an app with notes, comments, descriptions, long error messages, terms of service modals, or any meaningful prose, it matters a lot.
When dark is actually right
Dark mode wins in three cases, and we'll defend all of them: video editing and color-grading tools, where the UI needs to disappear so the content is judged accurately; tools used primarily at night or in dark physical environments (stage lighting consoles, observatory software, in-car displays); and developer tools where the user is staring at colored syntax-highlighted code for hours and a dark editor surface keeps the highlight colors from being washed out by the surrounding chrome.
If your product is not in one of those three buckets, dark mode is a marketing decision pretending to be a product decision.
The thing we now recommend
Ship light-only on v1. If a meaningful percentage of users ask for dark, build it as a proper second theme — not a tinted version of the light theme. That means a new palette, new chart colors, new gridline rules, new shadow rules, and probably a different typographic weight scale because dark UI tends to need slightly lighter weights to feel correct.
Do not ship "auto" by default. Auto theme switching based on OS preference sounds polite. In practice it means a user opens your app in the morning when their OS is in light mode, sets up their workflow against a light dashboard, then opens it after sunset and finds every visual reference they built has rearranged itself. We've seen support tickets that boil down to this exact confusion.
The version of this argument I'll defend hardest: a dark mode you don't have the budget to design properly is worse than no dark mode at all. Saying "we'll just invert the colors" is the design equivalent of "we'll just translate it with Google Translate." It's a tell that nobody senior owns the work.