Part of the v3.6.0 audit turned up a theme: small design-system drift.
Not "the site is broken on mobile" drift — more "if you open this specific overlay on an iPhone SE, it overflows." Individually, each one was a minor paper cut. Collectively, they were the kind of rough edge that made the platform feel less deliberate than it should.
TL;DR — four admin modals now fit iPhone SE-class viewports, the pricing table gracefully overflows-and-scrolls on mobile, the deploy wizard survives reloads, the debug logger is opt-in in production, and the brand accent is a single canonical hex instead of two near-identical ones. High-ROI work that doesn't earn a roadmap line but moves perceived quality up a notch.
This post is the story of cleaning that up.
The modal overflow pattern
Four admin overlays — custom domains, DNS records, k8s certs, and the domain form — all shared the same subtle bug. They used min-w-[280px] without a paired max-w, which on a 375px-wide viewport means:
"At least 280px wide, but please keep growing if the content wants to."
The content did want to — so the modal extended past the viewport, and the user ended up scrolling horizontally to find the "Dismiss" button.
The fix was mechanical: swap min-w-[280px] for
w-[min(calc(100vw-2rem),360px)]
That reads as "take 360px if there's room, otherwise take the viewport minus 2rem of margin." The modal now always fits.
The domain form modal had a related issue — a tall form could extend past the viewport vertically. max-h-[90vh] overflow-y-auto fixes that. These are standard idioms; they were just missing.
Pricing table, but make it scroll
The pricing comparison table had a similar mobile issue: a feature column at w-1/2 and three plan columns at w-[16%] each. On a narrow screen, the feature strings wrapped aggressively and the whole layout felt compressed.
We gave the table a min-w-[640px] and stretched its wrapper edge-to-edge on mobile with -mx-4 md:mx-0 px-4 md:px-0. On a 375px screen, the table now gracefully overflows-and-scrolls instead of compressing. Desktop is unchanged.
One accent colour, not two
The audit found 104 occurrences of #CDFF00 across 34 files, even though our canonical accent is #d2f800.
They're almost identical to the human eye — but "almost identical" is exactly the kind of thing that compounds:
- Some gradients didn't quite match.
- Some focus rings looked off against each other.
- Worst of all, the two hexes led a reviewer to ask "which one is actually correct?"
We ran a global sed to normalise everything to #d2f800 — the single canonical value, which is also the CSS variable var(--primary) — in one commit. This is a rare moment where "just do the sweep" was the right call instead of "gradually refactor file-by-file." The diff is trivially reviewable precisely because it's uniform.
Future work will keep pulling explicit hex values out in favour of CSS variables, but that's a design call about light/dark theming and is scheduled separately.
Deploy wizard: now it survives reloads
The deployment wizard asks you 5 questions before firing the actual deploy. Close the tab, reload the page, hit back in the browser — and all five answers were gone.
For a 60-second flow this is mildly annoying; for a first-time user still gathering credentials, it's the difference between completing and bouncing.
We added a sessionStorage-backed persistence layer with a few deliberate rules:
- Keyed per template/service — different wizards don't collide with each other's drafts.
- Saved on every mutation — no debounce needed; the payload is tiny.
- Restored on mount — up to and including step 5.
- Never resumes past step 5. Step 6 is the live deploy, which is SSE-driven and authoritative on the server — there's nothing meaningful to "resume" there.
- Cleared when a deploy starts so your next visit begins fresh.
Debug logger: now it's a support tool, not a fixture
There was a floating ./. button sitting in the bottom-right corner of deployment pages in production. It opens a popup window with a real-time log stream — extremely useful for debugging, extremely confusing for users who aren't debugging.
We kept the tool (it's genuinely useful) but flipped the default:
- In production, it's hidden.
- Support engineers — or users following a support walkthrough — enable it per-browser with
localStorage["boottify:debug"] = "1", or by hittingCtrl+Shift+D(Cmd+Shift+Don macOS) to toggle. - Dev builds still show it unconditionally.
The button's hardcoded hex styling was also replaced with design-system tokens while we were in there — because of course.
Heading regression
The marketplace hero page had drifted to font-bold on its h1. On a brand whose entire voice is font-black uppercase tracking-tighter, that's a jarring regression. Fixed, along with the bg-[#0A1628] hardcoded background that should have been bg-background.
The changelog's section-header icons — Plus, Wrench, Bug — got aria-hidden="true" as decoration. Screen readers now announce "New Features" once instead of announcing the icon's implicit role and then the heading.
Why these matter, bundled together
Any one of these in isolation is unimpressive.
But when a platform's mobile modals overflow, and the accent colour drifts, and a debug button shows to regular users, and the wizard loses your work on reload — the sum is a product that feels like nobody is looking after it.
Spending half a day straightening all six of them was high-ROI work: the kind that doesn't generate a line on a roadmap but does move the product's perceived quality up by a notch.
Next post in this series covers how we think about trust and transparency around user data — where Boottify stands, what we collect and why, and how the platform's privacy posture has evolved.
