The case for being the developer who designs
Specialization is good advice that's slightly wrong at the edges. What five years of holding both roles on the same project actually taught me.
The standard advice is to pick a lane. It's mostly right — depth beats breadth in a big organisation with dedicated roles for everything.
It's less right on small teams and client work, where the expensive failure isn't a weak design or a weak build. It's the gap between them.
What the gap costs
- Designs that specify states nobody can build in the timeline, discovered in week three.
- Builds that quietly drop the hover state, the empty state and the error state because they weren't in the mockup.
- Two rounds of revision spent translating between two vocabularies for the same thing.
What closing it buys
When the same person designs and builds, the design is already a specification of something buildable, and the build already knows the intent behind every spacing decision. Revision cycles collapse. So does the class of bug where the site technically matches the mockup and still feels wrong.
The honest trade-off
You will not be the best designer in the room or the best engineer in the room. You'll be the person who can get a considered thing shipped without a translation layer — and for a lot of projects that's the more valuable role.
Learn enough of the adjacent craft to respect its constraints. That's usually the whole return.
Rajat Bharti
Senior Web Developer in Bengaluru, IN. Writes about performance, automation and the parts of client work nobody documents.
