Start from one hue and expand only when the product proves it needs more. A single-hue system, built from one color stretched across tints, shades, and a neutral ramp, reads calm and cohesive and stays easy to control, because every decision lives inside one family and nothing can clash. A multi-hue system buys you more expressive and functional range, the ability to differentiate categories, signal states, and set distinct moods, but it pays for that range with harder balance, since every added hue is another relationship you have to keep from fighting the others. The call follows how much range the product actually requires versus how much control you want to keep, and the safe default is to begin narrow.
The reasoning is that range and control trade against each other, and most products discover they need far less range than they assume. One hue gives you a system that is almost impossible to make ugly: tints and shades of a single color are automatically related, so a designer working inside it can move fast and a developer can extend it without breaking harmony. The cost is expressiveness, since one hue cannot, by itself, carry several distinct meanings or strike contrasting moods. Adding hues lifts that ceiling but lowers the floor, because each new color multiplies the pairings you must tune, and a system with many hues left unbalanced slides straight into the circus problem. Starting narrow keeps the floor high while you learn what range you genuinely lack.
Take a focused productivity app. Built from one hue, say a single blue scaled from near-white to near-black with a gray neutral, it looks unmistakably coherent, every screen feels like one product, and the team rarely argues about color. Now suppose the app grows a reporting feature with six data categories that must be told apart at a glance. One hue can no longer do that honestly, so a second and third hue enter, reserved for the data, and the system becomes multi-hue out of real need rather than appetite. The expansion is earned, the new colors have jobs, and the original single-hue core still anchors everything around them.
Note one exception: some products genuinely start multi-hue because their core function is differentiation, and forcing those into one hue would cripple them. A map, an analytics tool, a tagging system, or anything whose primary value is distinguishing many things by color cannot pretend a single hue is enough; for them the multi-hue cost is simply the price of the job. So start-narrow is the default, not a law, and the real test is whether the product’s central work demands distinction. When it does, you build multi-hue deliberately from the start and accept the balancing burden as part of the brief.
When you set up a color system, begin with the tightest hue set that covers what the product does today, build it out in tints and shades before reaching for a second color, and add a new hue only where the product needs range one hue cannot provide. Let the demand for distinction, not the wish for variety, decide when you cross from one hue into several.