Most people in this industry pick a lane. You're either the developer who builds what the designer hands you — or you're the designer who passes off specs and hopes the developer interprets them right. The gap between those two chairs is where bad products are born.

I've sat in both chairs. For over six years, I've shipped production code and designed the interfaces that run on it. I've opened Figma in the morning and VS Code in the afternoon. I've written the component and designed the component. I know what it feels like to push back on a design because I understand the implementation cost — and I know what it feels like to push back on an implementation because I understand the user impact.

"UXPays exists because that gap — between design and development — is where most products quietly fail. And nobody's talking about it honestly."

Why this site exists

I started UXPays because I kept having the same conversation. A developer colleague would ask me to review their work, and I'd notice the same patterns: an error message that told the user nothing, a form with no persistent labels, a loading state that flickered in after the content already loaded. Small things. Easy fixes. But nobody had ever framed them as UX problems — just as details that got lost in the sprint.

The inverse was just as common. Designers who'd hand off specs with no empty states, no error states, no consideration for the edge cases a developer would inevitably ask about. Not because they were careless — but because nobody had shown them how a developer actually reads a design file.

UXPays is the blog I wish had existed when I was starting out. Practical. Technical. Written from the inside of both disciplines simultaneously. No fluff, no filler, no recycled tips from a 2019 Medium post.

What "both sides" actually looks like

As a Developer

  • Shipping Next.js applications across 38+ locales
  • Building component systems in TypeScript and Tailwind
  • CMS architecture with Contentful integrations
  • PostHog analytics and A/B test implementation
  • Core Web Vitals optimization — LCP, CLS, INP
  • Accessibility engineering to WCAG standards

As a Designer

  • UX/UI design for real estate clients and web products
  • Brand identity systems — logo, typography, color
  • Figma prototyping and design-to-code handoff
  • Editorial and print design sensibility
  • User flow mapping and information architecture
  • Visual hierarchy, typography, and spatial composition

What I actually believe about UX

  • UX isn't a phase in the process — it's present in every line of code. The moment you choose what an error message says, you're doing UX. The moment you decide whether a button is disabled or not, you're doing UX. There's no opting out.

  • The best UX decisions are made by people who understand constraints. A designer who knows why a developer would struggle with an animation. A developer who knows why a designer placed that button there. Shared understanding produces better outcomes than good intentions alone.

  • Performance is a UX problem first and a technical problem second. Users don't experience milliseconds. They experience trust, or the absence of it. A 3-second LCP is a broken promise, not a metric.

  • Human-made work has a quality AI can't replicate yet. Every article on this site comes from real experience — real mistakes, real production incidents, real client conversations. Not generated. Not summarized. Written.

  • UX pays. Literally. In salary, in promotion, in client trust, in conversion rates, in user retention. The title of this site isn't a metaphor. It's a provable statement. Every article here is evidence.

Design is a technical skill.

Typography, hierarchy, spatial composition — these aren't soft skills. They're learnable, practiceable, and measurable by the outcomes they produce. Developers can learn them. Most just haven't been shown how.

Code is a design tool.

The moment you write a loading state, choose a transition duration, or decide what an empty list says to a user — you're making design decisions. The code is the medium. The experience is the design.

The gap is the opportunity.

Most teams have designers who don't code and developers who don't design. The professional who bridges that gap isn't doing two jobs — they're doing a job nobody else on the team can do.