When users started requesting dark mode, my first instinct was "one day, maybe two." Add a CSS filter, invert the colors, ship it. Every developer has had this thought. Every developer who has actually shipped dark mode knows it is wrong.
A CSS inversion filter does technically create dark mode. It also makes your images look like photo negatives, turns your brand colors into their complementary opposites, and gives the entire application a vaguely nauseating quality that users cannot pinpoint but definitely feel. We tried it. We looked at it for about 30 seconds. We deleted it.
Real dark mode means redesigning every component for dark backgrounds. Not just swapping white for black -- actually thinking about contrast ratios, visual hierarchy, color psychology, and the specific way that text, icons, and interactive elements need to behave when the background is dark. It took us two weeks. Here is what we did and why.
Lazy dark mode is worse than no dark mode. If your dark mode looks like someone put a photo negative filter on the app, your users will switch back to light mode within a day and never try dark mode again.
The foundation of our dark mode is a two-color system: #0A0A0A as the base background and #32BAB0 (our signature teal) as the primary accent.
Pure black (#000000) on screens creates a jarring contrast with text and UI elements. The contrast ratio between pure black and pure white is 21:1 -- the maximum possible. That sounds good in theory but in practice it causes eye strain during extended use because your pupils are constantly adjusting between extremes. We chose #0A0A0A (a near-black that is just barely perceptible as not-quite-black) because it reduces the contrast ratio to a more comfortable range while still reading as "dark" to the eye.
From #0A0A0A, we built a scale of dark grays for different elevation levels:
This elevation system creates visual depth without relying on shadows, which are nearly invisible on dark backgrounds. In light mode, a card floats above the page because of its shadow. In dark mode, a card stands out because its background is one shade lighter than the page behind it.
Our teal accent was originally designed for light backgrounds. The good news: it works beautifully on dark backgrounds too, but only because we tested it. Teal on near-black has a contrast ratio of 7.3:1, which exceeds WCAG AA requirements for both normal and large text. The color pops without being harsh. It draws attention to interactive elements (buttons, links, active states) without competing with content.
We did have to adjust one thing: the teal's opacity in subtle contexts. On light backgrounds, we use teal at 10% opacity for tag backgrounds and hover states. On dark backgrounds, 10% teal is invisible. We adjusted subtle teal to 15% opacity in dark mode, which provides the same visual weight without changing the color itself.
The pipeline board was the most complex dark mode challenge. Each stage column has a colored header (blue for "New Lead," yellow for "Qualified," green for "Closed Won," etc.). On a white background, these colors work as soft pastels. On a dark background, the same pastels look washed out and muddy.
We created a dark mode variant for each stage color: slightly more saturated, slightly more vibrant, with adjusted lightness values. The blue header that is #EBF5FF in light mode becomes #1A2D4A in dark mode -- still recognizably blue, but optimized for a dark surround. We went through this exercise for all seven default stage colors plus the 12 custom color options.
The activity timeline was where we spent the most time per component. The timeline has a vertical line connecting events, small circular icons for each event type (email, call, note, deal change), timestamps, and content previews. In light mode, the line is light gray and the icons use colored backgrounds. In dark mode, the line needed to be darker than the background (inverted from light mode logic) and the icon backgrounds needed to shift to outlined styles to avoid bright color blobs against the dark background.
We also changed the timestamp treatment. In light mode, timestamps are gray text. In dark mode, we found that gray-on-dark-gray timestamps were almost invisible. Instead of increasing the timestamp brightness (which would draw too much attention), we added a subtle 1px left border in teal to each event group, giving the eye a structural reference point that compensates for the lower timestamp contrast.
Our analytics charts use a palette of six colors for multi-series data. Every single one of those colors had to be re-evaluated for dark backgrounds. The light mode green (#10B981) at full saturation on a dark background was neon-level bright. We desaturated it to #0D9668 for dark mode. The light mode orange (#F59E0B) looked fine on dark, so we kept it unchanged. Each color was individually tested for accessibility and visual harmony.
Grid lines in charts went from light gray (#E5E7EB) to dark gray (#2A2A2A). Axis labels went from medium gray (#6B7280) to light gray (#9CA3AF). The tooltip background inverted from white-with-shadow to dark-with-border. Every micro-decision matters because charts are information-dense -- a wrong contrast choice in a chart legend means users misread their own sales data.
Dark mode is not a theme toggle. It is a complete visual redesign that happens to share the same layout and functionality as the light version.
SalesSheet supports three dark mode settings: Light, Dark, and System. The System option uses the CSS prefers-color-scheme media query to match whatever your operating system is set to. If your Mac switches to dark mode at sunset, SalesSheet switches with it. If you manually toggle your OS theme, SalesSheet follows within milliseconds.
This sounds trivial to implement (it is one media query), but the edge cases required thought. What happens when a user has System mode enabled and is in the middle of editing a deal? We ensure the transition does not reset any form state or scroll position. What about the pipeline board, where users might be mid-drag on a deal card? We delay the theme transition until the drag-and-drop interaction completes. What about the email compose window, where the user is writing in a rich text editor? We transition the chrome (toolbars, sidebars) immediately but fade the editor background over 200ms to avoid a jarring flash mid-sentence.
Mobile dark mode was a separate project with its own challenges. The mobile app uses different component patterns (bottom sheets instead of modals, swipe gestures instead of hover states, native switches instead of custom toggles). Every mobile component needed its own dark mode treatment. We also had to account for OLED screens, where true black (#000000) actually saves battery. On the mobile app only, we offer an "OLED Black" option that uses #000000 instead of #0A0A0A as the base background.
Dark mode has been live for three weeks. Here is what the data shows:
The zero-support-tickets number is the one I am most proud of. It means the two weeks we spent on component-by-component polish paid off. Users enabled dark mode and it just worked. No "I cannot read this text" complaints. No "this chart looks wrong" reports. No "my eyes hurt" feedback. It just looks right.
I know dark mode is not a revenue-driving feature. Nobody signs up for a CRM because it has dark mode. But people stay with a CRM that feels good to use for eight hours a day. Polish is the accumulation of a thousand small decisions that individually seem insignificant but collectively determine whether your product feels professional or feels like a prototype.
Dark mode was our way of saying: we care about every pixel, even the ones you only see at night.
Sin tarjeta de crédito. Comienza a vender de forma más inteligente hoy.
Comenzar Prueba Gratis