What Building My Own Site Taught Me About Mobile-First Development
The gap between "it works on desktop" and "it works everywhere" is bigger than you think — lessons from building CIMLAS Bespoke Solutions in production.
Raymond
The irony isn't lost on me.
I build websites for a living. Precision-engineered, custom-coded, no shortcuts. And yet, when I launched CIMLAS Bespoke Solutions, my own site had a horizontal scroll gap on mobile that I couldn't pin down for weeks.
That's the thing about building in public — your standards get tested in real time.
Here's what I learned.
The Problem Nobody Warns You About: The Pinch-Zoom Gap
It started with a simple observation. On desktop, the site looked exactly how I designed it. Clean. Sharp. No overflow. But on mobile — specifically on Android Chrome — users could pinch-zoom out and reveal a ghost column on the right side of the screen.
Not a scroll bar. Not a padding issue. A full invisible overflow zone that made the page feel broken.
I chased it across every component. I checked paddings. I checked max-widths. I reduced clamp values. Nothing fixed it.
The real culprit? Three separate sources, all compounding:
- A
whiteSpace: nowrapon footer nav links forcing the document wider than the viewport - A Three.js WebGL canvas with 3D perspective transforms painting outside its container bounds
- No
overflow-x: hiddenon the<body>— only on individual sections, which doesn't prevent the document itself from expanding
The fix for #3 was one line in app/layout.tsx:
tsx
<body style={{ overflowX: 'hidden' }}>
One line. Two weeks of intermittent debugging. That's mobile development.
Three.js in a Nav Bar Was a Mistake
I'll be honest — the 3D rotating icons in the nav looked incredible on desktop. An astronaut helmet for the About page. A glowing tech cube for Services. A burnished gold gear for Process. Each one a tiny WebGL canvas, fully lit, slowly rotating.
They also caused hydration mismatches, added 200KB+ to the bundle, and on certain mobile browsers triggered layout shifts that broke the entire nav alignment.
I replaced all five with inline SVGs. The result? Faster load, zero layout issues, and honestly — they still look great. A blue person icon. An orange grid. A purple monitor. A gold star. A green document.
Sometimes the right engineering decision is the simpler one.
clamp() Is the Most Underrated CSS Function
Before this build, I used media queries for responsive padding. Specific breakpoints, specific values, done.
This site changed how I think about it. Every section now uses clamp() for padding:
css
padding: clamp(100px, 15vw, 140px) clamp(20px, 5vw, 48px)
The result is a layout that doesn't snap — it flows. There's no jarring reflow at 768px. The spacing breathes naturally across every screen size, from a 375px iPhone SE to a 1440px desktop.
It's a small thing. But small things compound into polish.
The Alternating Layout Problem
The portfolio page uses an alternating card layout — even cards show image on the left, odd cards show image on the right. It looks great on desktop. On mobile, when the grid collapses to a single column, odd cards were rendering content first and image second — which means users were reading a title and description before they even knew what they were looking at.
The fix was one CSS media query:
css
@media (max-width: 640px) { .card-image { order: -1 !important; } }
Image always comes first on mobile. Content follows. The reading flow makes sense.
What I'd Do Differently
If I were starting over, I'd build mobile-first from day one — not as an afterthought after the desktop version was "done."
I'd also be more disciplined about overflow-x: hidden at the root level early, not after chasing bugs for days.
And I'd think twice before reaching for WebGL in a navigation bar.
The site is better for all of it. Every bug I fixed made me a sharper engineer. That's the value of building your own production system — you can't hide behind a client's acceptance criteria. The only standard is yours.
TAGS