Design for technical founders: work your engineers can build

Many SaaS and AI companies are started by engineers. They can read a diff in seconds and spot a race condition in a review, but a design proposal arrives as a set of pictures, and the only available reaction is “looks good” or “I don’t like it”. Then the pictures go to engineering, someone translates them into code, and a few weeks later the product looks a bit like the design and a bit like whatever was easiest to build.

Both problems have the same fix: treat design as something with a spec, a structure and a build, like the rest of your product.

How do you judge a design proposal as an engineer?

Judge design the way you judge code: does it solve the right problem, is it consistent, and can it be maintained? Four questions cover most of it:

• 01Does it state the problem and the user it solves for? A proposal that starts with screens instead of a problem is like a pull request without a description.
• 02Are states covered: empty, loading, error, permissions? The happy path is the easy part. What a new user sees with no data, or an admin sees without access, is where products feel finished or not.
• 03Is it consistent: same components, same spacing, same patterns? A new button style for one screen is the design version of a copy-pasted function.
• 04Can it be built with what you already have? Good design reuses the system. If every proposal needs new components, ask why.

You don’t need taste to ask these. You need the same habits you already use in code review. Taste still matters, but it’s much easier to discuss once the basics are covered.

Design to engineering without a translation step

The translation step is where design gets lost. A designer draws a screen, an engineer reads it, guesses the values, rebuilds the components and fills in the missing states. Every guess is a small drift. Removing the guesses takes four things:

• 01Tokens in code from day one. Color, type, spacing, radius and shadow as variables in the repo, so nobody reads a hex value off a screenshot.
• 02Components named the same in design and code. If the design says “Banner, warning”, there should be a Banner component with a warning variant.
• 03Specs for behaviour, not just visuals. What happens on submit, on error, on a slow network, on a small screen.
• 04A working development environment where the design runs as real UI, not just a picture of it. Engineers can open it, click through it and copy from it.

Nothing should have to be translated from a picture.

This matters more now that many teams build with AI coding tools. A tool given tokens, components and written rules will extend your system. A tool given screenshots will approximate them, and every approximation becomes code someone has to maintain.

What should you ask a design partner?

Before you hire anyone, ask how the work reaches your engineers. The answers say a lot about how much translation you’ll be paying for later. For a broader list of questions, see Choosing a design partner when AI can make anything.

• 01How do you hand off: files, tokens or code?
• 02Can you work in our repo and our tools?
• 03Who keeps the design system up to date once the project ends?
• 04How do you cover states and edge cases, not just the main screens?
• 05Can you explain a design decision in terms of the problem it solves?

How we work

We hand over three things your engineers and AI coding tools can use directly: design tokens for every value, markdown files (like a DESIGN.md) that explain how and when to use each part, and a development environment where the design already runs as code. Nothing has to be translated from a picture.

• 01Design tokens: every color, type size, spacing step, radius and shadow, named by role.
• 02Markdown files: the intent behind the system, which component to use for what, and the rules not to break.
• 03A development environment: the design running as real UI, with the states covered, ready to read and build from.

We still explore in design tools when it’s the fastest way to compare directions. What reaches engineering is built to be used, not redrawn. For why one person designing and building removes so many handoffs, read The return of the generalist.

Where to start

For a new product, a Launch sprint (from US$12k, about four weeks) covers the core product flows, the identity system and a UI kit, handed over the same way. For a product that already shipped, a design partnership (from US$6k/mo) works through it one focus at a time, starting with the system. Details on our partner page.

If you want design that arrives ready to build, send your brief.

• Product
• Systems
• Process