Interface design when engineers also build it: fewer cycles, better products

Summary: The fastest UI quality comes from designing and building in the same codebase—real components, real data, and explicit UI states—not pixel-perfect handoffs.

Design and engineering are usually two teams sitting in different tools, speaking different languages, and discovering each other's constraints during code review. The result is a product that feels stitched together — because it is. We do it differently: the people drawing the interface are the people building it. Here is what changes when you remove the handoff.

The hidden cost of design handoff

A typical design-then-build cycle goes: 4 weeks of Figma, 2 weeks of "design review", 1 week of "engineering questions", 6 weeks of build, then a frustrating month of "this is not what the mockup shows" tickets.

The problem is not bad designers or bad engineers. The problem is that Figma cannot enforce real constraints — performance, accessibility, edge-case data, loading states, error states, empty states. Designers draw the happy path; engineers discover the other 80% on Wednesday at 4pm.

What we do instead

1. Sketch in low-fidelity, build in real code

We use Figma for whiteboard-level exploration only — boxes, arrows, copy direction. The moment a flow is roughly agreed, we build it in real code with real data. Iteration happens in the actual app, not in a static mockup.

2. A real component library, used by the same person who draws

Tailwind + shadcn/ui + a small set of project-specific components. The designer-engineer composes screens the same way they would in Figma, except the result is shippable. There is no "design system" maintained separately from production.

3. Real data from day one

No lorem ipsum. No "John Doe". We pull real user names, real long company names that overflow, real empty states, real error states. The product looks 10× better at the demo because it has been stress-tested since week 1.

The states designers usually forget

Almost every Figma file we have ever received was missing at least three of these. They are also where most "the app feels janky" complaints come from:

• Empty states with onboarding. Not "no data found" — actual guidance for what to do first.
• Loading states. Skeletons, not spinners. Match the layout of what is loading.
• Error states. Specific, not generic. "We could not save — your session expired" beats "Something went wrong."
• Long-content states. What happens when the company name is 80 characters? When the description has 12 paragraphs?
• Permission states. What does a viewer see vs an admin? When are buttons hidden vs disabled vs visible-but-explained?
• Mobile. Not a "responsive version" — a real mobile design, with mobile-first interactions.

What we have stopped doing

• Pixel-perfect mockups. They are obsolete the moment a real string is longer than expected.
• Design review meetings without a working build. Opinions on a static screenshot are worth a fraction of opinions on a clickable prototype.
• Custom design systems before product-market fit. shadcn/ui + Tailwind covers 90% of cases. Build your own only when the brand is the product.
• Animations as a feature. Most "delightful" animations slow people down. We use motion only to communicate state changes, never as decoration.

The result, measured honestly

On recent projects, the time from "first screen sketched" to "screen in production" dropped from ~5 weeks to ~1.5 weeks. Design-related bug tickets dropped by roughly 70%. The number of "this is not what we agreed" meetings dropped to almost zero — because the thing being discussed is always already running.

Good interface design is not a deliverable. It is a property of a product that has been built and re-built by people who care about both how it looks and what it does.