1
1 Comment

Design is ALIVE!

Design is more important than ever.

The design process is compacting. What used to take weeks of discovery and workshops can now happen in a day. AI can generate a working
prototype from a paragraph. Founders who've never shipped a product before are watching their idea appear on a screen in hours and thinking
they've cracked it.

The output is impressive. I get it. If you've never done this before, seeing something functional and visually coherent emerge from a prompt
is genuinely exciting.

The problem is it all looks the same.

Not always on the surface. AI tools have got good enough that the first pass can wow you. But there's a layer underneath that gives it away:
the flows that break when a user does something unexpected, the spacing that's slightly off in ways that register subconsciously, the
onboarding that made sense to the person who built it but confuses everyone else. The visual design that's competent but forgettable.

Founders building their first product don't have the reference point to spot this. Why would they? The output is better than anything they've
made before. It takes someone who's looked at a lot of designs, who knows what good actually looks like in practice, to see where it's gone
wrong.

AI gave designers the ability to build rather than just paint. That sounds small but it's not. Designers have always been the ones who could
see what something should be, but the limitation was always that someone else had to build it, and things got lost in that translation. Now
that gap is almost gone. The component, the interaction, the thing that lives in the browser, a designer working with AI can ship that
directly. No handoff, no "that's not what I meant," no multiple rounds of back and forth.

There's another exciting thing that happens when you design in code rather than on a canvas. Edge cases surface immediately. Error states,
interactions, what happens when the data's empty or the input's wrong, these things are inconceivable in a static design but unavoidable the
second you're building the real thing. Problems that would have shown up two weeks into development, get caught on day one. Nothing gets lost in the translation from pixel to product because there is no translation.

That changes where design sits in the build. It can be at the start, before a single line of code exists, shaping the foundations
and stopping the generic path before it's taken. Or it can come in at the end, catching what slipped through. Both are valid. Both save more
time than they cost.

The hiring question is harder to answer than it used to be. Everything's moving too fast for a founder to commit to a full-time designer. The old models just haven't caught up with that reality.

So I aim to fix this by working as a design partner. Month to month, cancel anytime, from the start of a build or later, sprint-based or ongoing. It fits
around what the company actually needs rather than locking anyone in.

If you're building something and you can feel that something's slightly off but can't put your finger on it, that's usually design. Happy to take a look.

on April 30, 2026
  1. 1

    Designing in code acts like a live debugger, catching structural edge cases before they turn into expensive post-launch post-mortems.
    While AI handles the initial pixel push, your role as a partner ensures the product escapes the uncanny valley of generic, prompt-generated UX.
    Do you find that founders are more receptive to code-based design once they see how many Jira tickets it kills in advance?