Why We Rebuilt Muqira's Design System from the Ground Up

What changed

For a long stretch, Muqira used a warm, editorial palette — off-whites, deep warm blacks, Cormorant Garamond doing heavy lifting at large sizes. We liked it. A lot of our users noticed and mentioned it. It felt considered and slightly unusual in a space where most software defaults to the same clinical blue-grey.

But something kept nagging. The warm palette felt personal. Thoughtful. Maybe a little precious. As the product ecosystem grew and we started thinking seriously about what Muqira should look like at scale — multiple products, enterprise users, a parent company positioning — warm and precious did not feel like the right register anymore. We wanted something that read as serious technology. Something that felt like it had been around for a while and planned to stick around.

So we rebuilt. Not a refresh — a rebuild, with first-principles thinking about what the brand needs to communicate and what role the visual system plays in communicating it.

The palette decision

The core background is now #0B1020 — a deep navy that sits closer to the blue end of the spectrum than to black. This was a deliberate choice. Pure black can read as harsh, stylised, or theatrical. Dark grey reads as neutral and slightly boring. Deep navy reads as considered, technical, and premium — which is exactly the register we wanted.

The secondary surface is #131A2E, just enough differentiation from the background to create depth without reaching for harsh borders. Text lands at #F7F8FA — not pure white, which would be too stark — with a cascade of ink variables from full opacity down to the ghost tones we use for secondary metadata and disabled states.

We spent a surprising amount of time on the light mode, which is often an afterthought in dark-first design systems. Ours uses a cool slate palette rather than the warm off-whites from the previous version — #F5F6FA as the base, desaturating toward the same blue undertones that anchor the dark mode. The result is two modes that feel like the same brand rather than two different products.

Typography choices

Cormorant Garamond stays for display use. At large sizes — the kinds of headlines that anchor a hero section or a section break — it carries editorial authority in a way that no geometric sans can match. It is not a fashionable choice, but it is the right one for what we are trying to communicate.

For body text and UI, we switched from DM Sans to Instrument Sans. The difference is subtle but real — Instrument Sans has slightly more personality at small sizes without sacrificing the neutrality you need for dense information. JetBrains Mono handles all the monospace work: metadata, timestamps, technical labels, code snippets.

How the token system works

Everything lives in CSS custom properties scoped to a data-theme attribute on the HTML element. The dark mode values are defined at :root and [data-theme='dark']. The light mode values override at [data-theme='light']. Every component references tokens — never raw hex values.

This means there is no JavaScript conditional rendering for themes. No checking a context value and returning different JSX. Theme switching is a single setAttribute call on the HTML element. The DOM does not change. The components do not re-render. The CSS cascade does all the work, instantly, with no flash.

Getting light mode right

Light mode is where most design systems fall apart. The token values get redefined but the component-level decisions — border widths, shadow intensities, spacing — often assume a dark background. Shadows that look great on dark backgrounds look muddy on light ones. Borders that are invisible on dark surfaces suddenly feel heavy on light ones.

We audited every component in light mode before shipping. Shadow values are lighter. Border opacities are different. The result is a light mode that does not feel like an afterthought, which is rarer than it should be.