Why I Design, Code, and Ship — And Why the Industry Needs More People Who Do

The separation between design and development creates handoff friction, lost details, and slow feedback loops. Here's why I do both — and why more people should.

amejia
amejia
· 3 min read

In most organizations, design and development are separate disciplines with separate teams, separate tools, and separate timelines. A designer creates mockups. A developer builds them. A product manager referees the translation. Misalignment, handoff friction, and “that’s not what I designed” conversations are accepted as normal.

I don’t work that way. I design the interface, write the code, and ship the product. Not because I’m trying to be a unicorn — because the separation between design and development creates problems that disappear when one person does both.

The Handoff Tax

Every handoff between designer and developer is a lossy compression. Details get lost. Intentions get misinterpreted. Edge cases that the designer thought about but didn’t document get built incorrectly or not at all.

I’ve been on both sides of this. As a designer, I’ve watched developers implement my designs with wrong spacing, missing states, and broken responsive behavior. As a developer, I’ve received designs with undocumented interactions, impossible layouts, and components that don’t account for real data.

When one person handles both, the translation loss is zero. The design intent survives because the person who created it is the same person implementing it.

Faster Feedback Loops

When I’m designing in Figma and I have a question about technical feasibility, I don’t need to ask a developer. I know the answer because I am the developer. When I’m writing code and I realize a design decision doesn’t work at certain screen sizes, I don’t need to go back to the designer. I adjust the design on the spot because I am the designer.

This collapses feedback loops from days to seconds. Problems get caught and solved in the same sitting. The result is a product that feels cohesive because every decision was made with full context.

What This Looks Like in Practice

My typical workflow for a new feature:

  1. Research: Understand the problem, the users, and the constraints.
  2. Sketch: Quick wireframes in Figma to explore layouts and flows.
  3. Build: Jump straight into code, using the wireframes as a guide. Tailwind CSS means the styling happens in the markup — no separate design-to-code step.
  4. Refine: Iterate in the browser with real data, real interactions, and real responsive behavior.
  5. Ship: Deploy and get it in front of users.

There’s no handoff document. No design spec. No “here’s the Figma link, please match this exactly.” The design and the code evolve together because they’re being built by the same brain.

The Industry Needs More of This

I’m not saying every designer needs to code or every developer needs to design. Specialization has its place, especially in large organizations. But the industry has a massive shortage of people who can do both — and the demand is growing.

Startups need people who can go from concept to shipped product without a team of specialists. Agencies need people who can deliver complete projects, not just one piece of the puzzle. Product teams need people who understand the full stack of decisions from user need to deployed feature.

The most impactful products I’ve seen come from small teams (or individuals) who own the entire process. They ship faster, iterate more freely, and produce more cohesive experiences because there are no gaps in the pipeline.

How to Build This Skillset

If you’re a designer who wants to code: start with HTML and CSS. Build your own designs. Then learn JavaScript and a framework. You don’t need to be a senior backend engineer — you need to be competent enough to build and ship what you design.

If you’re a developer who wants to design: start by studying what makes existing products feel good. Learn the principles of visual hierarchy, spacing, and typography. Use your product critically — notice what feels polished and what feels off, then figure out why.

The sweet spot isn’t being world-class at both. It’s being good enough at both that you can own the entire process from concept to production. That’s where the real leverage lives.