Most projects lose 30 percent of their timeline and a chunk of their design fidelity at the handoff. Somebody designs a beautiful Figma file. Somebody else translates it into code. The translation is lossy, the communication is patchy, and two weeks in, the developer has rebuilt a component three times and the designer is angry about spacing.
I don't have that problem because I'm the designer and the developer. The handoff is a thirty-second walk from one window to another. But the process matters even solo, because without a process, the design drifts and the code grows weeds.
Here's what I do.
Design and build the system first, pages second
Before I write any real code, I build the design system inside the Figma file:
- Typography scale with real line heights
- Color palette with actual contrast ratios checked
- Spacing scale (I use a 4-point grid)
- Component set with every state and variant defined (hover, focus, disabled, loading, error)
- Motion primitives (easing curves, durations)
Then I translate that system into a matching set of CSS variables and Tailwind config. Every Figma token has a code token. Nothing gets hand-coded twice.
This is the step most projects skip and the one that saves the most time later.
Component-based, not page-based
I don't build pages. I build components in isolation and then assemble them into pages.
A button exists once. It has five variants and four states. When the design changes, I update the component, and every page that uses it updates automatically. When a state is missing (what happens to this button while the form is submitting?), I notice it at the component level, not two weeks later in QA.
Storybook or an equivalent helps here, but for small projects I usually just build a /design-system route in the app itself and render every component on it.
The stack
For most projects:
- Next.js for the app framework
- Tailwind CSS with a custom config matching the design system
- TypeScript everywhere
- Vercel for hosting
- Postgres + Drizzle or Prisma if there's a database
It's boring. That's the point. Boring stacks ship.
Pixel parity, within reason
I check the live implementation against the Figma at the end of every feature. Side-by-side browser window, Figma open on the other monitor. Spacing, type, color, and interaction all match.
I don't chase sub-pixel perfection. I do chase consistency. If the button padding is 14 in the design and 16 in the code, that's a real inconsistency. If it's 14 versus 13.5 at a fractional devicePixelRatio, I move on.
Accessibility in the loop, not at the end
Every component gets:
- Semantic HTML (real headings, real buttons, real labels)
- Keyboard navigation (tab order, focus rings, escape-to-close)
- Screen reader labels where visuals alone don't communicate
- Color contrast meeting WCAG AA minimum
Retrofitting accessibility after shipping is miserable and expensive. Building it in costs nothing extra.
Performance, also in the loop
- Images go through Next's image pipeline with proper sizing
- Fonts are self-hosted and subsetted
- No render-blocking scripts unless genuinely required
- Lighthouse scores audited before launch
A client's site should load in under two seconds on a cold 4G connection. If it doesn't, something's wrong.
What "done" means
Before I ship, a project has to clear:
- Design matches across all breakpoints (mobile, tablet, desktop)
- Works in Chrome, Safari, Firefox, Edge
- Lighthouse performance and accessibility both 90+
- All forms submit, all links go where they're supposed to, all states exist
- Error and empty states designed and implemented, not left as todos
- Readable code committed with sensible commit messages
- Deployment pipeline set up and verified
That's the bar. Short of it, it's not done.
The honest caveat
This process works because I'm one person making every decision. On a team, the same process needs heavier tooling (Storybook, Chromatic, design tokens sync, proper handoff documentation). The principle is the same: build the system first, assemble pages from it, check everything against the design at every step.
If you want a site or app built this way, tell me what you need.