How I Learned to Ship a UI by Turning Constraints into a Design System

It was 2 a.m. on a Tuesday, and the only light in my home office came from the glow of the laptop screen. I had just pushed the latest version of iCharles to production, and the Button component I’d been tinkering with for hours still looked like a mismatched collection of background‑color, border‑radius, and font‑size hacks.

My inbox pinged with a notification from a new user who had just signed up. The welcome email I’d sent earlier that week proudly proclaimed, “Your community is ready.” When I clicked the link in the email, the button that should have said “Enter Community” stared back at me in an ugly shade of teal that didn’t match any other element on the page. It felt like a slap.

In real estate, I was used to closing a deal with a clean handshake. Here, I was staring at a UI that looked like a collage of borrowed styles. I had spent the past week ripping CSS from three sites I admired— the minimalism of Basecamp, the bold typographic hierarchy of Stripe, and the playful spacing of Notion. I copied snippets, tweaked colors, and pasted them into inline style attributes inside my Elysia templates. The result was a page that technically worked, but every element fought for attention.

When the third attempt broke

The third time I tried to make the Button look decent, I realized I had written the same background: #ff6600; rule in three different places. I was hard‑coding hex values, ignoring the design language I’d been trying to emulate. My mind raced back to the countless property listings I’d once staged: I would bring in a few decorative pieces, but the room never felt cohesive until I followed a single palette.

I deleted the inline styles, lifted my head, and stared at the empty button tag. The page rendered a plain, gray rectangle with the default browser font. It was ugly, but it was honest. I could finally see what I had built without the veneer of borrowed CSS.

Introducing a tiny constraint

That night I opened the styles.css file I kept for “quick fixes” and added a single line:

:root { --pm-primary: #0069ff; --pm-bg: #f9fafb; --pm-radius: 0.5rem; }

Instead of reaching for a hex literal every time I needed a color, I forced myself to reference one of the three custom properties. The first button I styled after that used background: var(--pm-primary);. The second used color: var(--pm-primary);. The third used border: 1px solid var(--pm-primary);. Suddenly the three buttons shared a visual DNA. I felt a faint grin spread across my face.

It was a minuscule constraint—no more than three variables—but it was enough to make the page feel intentional. I added a fourth variable for a subtle gray background and a fifth for the border radius. With those in place, every component I built had to choose from the same palette.

Building the primitives

From there, I sketched out a tiny design‑primitives system:

• Button – a button element that accepts variant="primary|secondary" and applies the appropriate CSS variables.
• Input – an input style that uses --pm-bg for its background and --pm-radius for its corners.
• EmptyState – a container that shows a message when a list is empty, using the same type scale and spacing tokens.

I wrote each component in its own file, exported a single ui.css that bundled the variables and the component classes, and imported that file into every Elysia route. No more inline styles. No more copy‑pasting from other sites. The moment I imported ui.css into the “community” page, the header font, the button color, and the input background all sang the same note.

Because the system was so small, I could reason about every change in my head. When I decided the primary blue was too harsh, I changed --pm-primary from #0069ff to #0055d9. The change propagated instantly across every button, link, and border that referenced the variable. I felt the same satisfaction I used to get when a buyer accepted an offer after I adjusted the price by a few thousand dollars.

The crash that taught me humility

Two weeks later I decided to add a dark‑mode toggle. I created --pm-bg-dark and --pm-primary-dark, and wrote a small JavaScript snippet that swapped the :root variables when the user clicked a switch. I tested it locally, refreshed the page, and everything looked fine—until a user reported that the “Create Post” button vanished on the community feed.

Debugging in the console, I discovered I had forgotten to add the dark‑mode variable to the Button component’s CSS. The button fell back to the default background: transparent, making it invisible against the dark background. In real estate, a missing clause in a contract could void a sale; here a missing variable broke the experience.

I rolled back the change, added a fallback value to the button’s CSS, and re‑released. The incident reminded me that constraints are only useful when they’re complete. A design system is a contract with yourself, and you have to honor every term.

What constraints taught me

Constraints forced me to stop chasing the perfect pixel from someone else’s stylesheet and start asking, “What does this component need to communicate?” By limiting the palette, the spacing scale, and the radius, I let the content decide the visual hierarchy instead of the other way around.

Most importantly, the constraint turned a lonely developer into a designer. I no longer needed to study every design system on the internet; I only needed to maintain the handful of variables that defined iCharles. The rest of the UI fell into place, and I could ship new pages in a single afternoon instead of a week of trial‑and‑error.

Now, when a junior developer asks me how to style a card, I point them to the ui.css file and say, “Pick a variable, not a hex.” The lesson is simple but profound: give yourself a narrow runway, and you’ll find the runway extends far enough to take off.