Your users expect dark mode. Whether you build it now or later, you will build it -- and how you build it determines whether it stays easy or becomes the thing you quietly regret.
Most tutorials teach the wrong approach. They show you how to add dark:text-white and dark:bg-gray-900 to individual elements. It works for a demo. It breaks for a real product.
When you add dark mode by toggling utility classes per element, each new component becomes a question: did I remember the dark variants? A data table where the rows disappear. A card where the background blends with the text. A modal that looks broken at night.
The pattern scales poorly. You end up auditing every component when you ship a new page, and it never quite catches everything. Six months in, dark mode is the second thing -- after mobile responsiveness -- that contributors break without realizing it.
If you are evaluating whether to build from scratch or use a boilerplate, Next.js SaaS Boilerplate vs No-Code -- Which Should You Use covers the tradeoffs in detail. Dark mode setup is one data point in a larger comparison.
The correct approach uses CSS custom properties (variables). Instead of hardcoding a color on an element, your components reference a variable. When dark mode activates, only the variable values change -- every component updates automatically, including ones you add next week.
It looks like this in practice:
/* globals.css */
:root {
--background: 0 0% 100%;
--foreground: 222.2 84% 4.9%;
--card: 0 0% 100%;
--muted: 210 40% 96.1%;
}
.dark {
--background: 222.2 84% 4.9%;
--foreground: 210 40% 98%;
--card: 222.2 84% 4.9%;
--muted: 217.2 32.6% 17.5%;
}Any component that uses bg-background and text-foreground from Tailwind automatically picks up the right values in both modes. You write the component once. Dark mode comes free.
The toggle is also straightforward. The next-themes library gives you a useTheme() hook with a setTheme() function. A theme button is a handful of lines, no custom logic required.
If you were starting without a boilerplate, adding dark mode correctly takes a half-day:
1. Install and configure next-themes in your root layout
2. Rewrite your entire color system as CSS custom properties
3. Configure Tailwind to reference those custom properties
4. Set the dark mode class strategy in tailwind.config.ts
5. Audit every existing component to remove hardcoded colors
Most teams skip steps 2 through 5 and bolt dark mode onto an incompatible color system. That is where the class-per-component pattern comes from. It is not a design choice -- it is a workaround for a foundation that was not built for theming.
The Next.js SaaS Boilerplate handles all of this before you write a line of product code:
next-themes is installed and wired into the root layout providerglobals.css defines the complete light and dark palettes as CSS custom propertiesWhen you add a new card, table, or modal, it picks up the correct background and text colors in both modes automatically. You do not touch dark mode again unless you are changing the palette itself.
The theme toggle is already in the header. Your users can switch on first visit. If you want to read through the full setup before you start, check out the getting started guide.
Dark mode is not a cosmetic preference for most users -- it is an expectation on any SaaS launched in 2026. A product that ships without it looks unfinished. A product that ships with broken dark mode looks worse than one without it.
Getting the foundation right means you never have to refactor it. Every Shadcn component you add works. Every page you build works. Dark mode becomes a feature you have, not a debt you owe.
If you are already building on the boilerplate, dark mode is done. If you are deciding whether to start from a boilerplate or scratch, the dark mode setup is one afternoon of the week you will save before you write your first feature.
Get the boilerplate and ship your SaaS idea this weekend.