The relationship between software products and dark mode has flipped in the developer tools and B2B SaaS category. Where dark mode used to be the opt-in “for late-night coding” preference, a growing set of products are shipping it as their default skin, with light mode available as the toggle.
The drivers are partly audience-driven. Developer tools are used primarily on monitors in offices and home offices, in environments where ambient lighting is controlled, and by users who have demonstrated preference for dark interfaces through years of terminal use and IDE customization. Defaulting to dark mode for this audience is a reasonable prior.
But the more significant driver is design intent. Several of the most distinctive developer-tool brands of the last few years (Linear, Raycast, Warp, Vercel’s dashboard) are products that were designed dark-first. Their component libraries, their color systems, their typographic hierarchy: all of it was spec’d on dark surfaces and adapted to light mode as a secondary pass. The result is that the dark mode on these products looks intentional and the light mode looks like an accommodation. Users picking up on that signal increasingly trust the default.
The practical implication for design teams: if you’re building a developer tool or a technical B2B product and your primary users work in dark IDEs, defaulting dark is no longer a bold choice. It’s a table-stakes decision. The design work is in making the light mode genuinely good rather than an afterthought. Linear does this reasonably well. Most others don’t bother.
What’s not working: dark-by-default on products with broad non-technical audiences. Consumer-facing products, e-commerce platforms, and anything with a significant mobile-only user base are still predominantly light-default, and for good reason. The cognitive load of a dark screen in outdoor daylight is real. The “default dark” trend is audience-specific, not universal.