The Designer Who Codes Argument Is Over

The debate ended without a winner. It ended because the distance between a design and a running product got short enough that arguing about who should cross it stopped making sense.

I design and build my own products. Ring-Rival, Stips, HerbaLink, CatchBuddy are all live, all built solo. I'm not an engineer and I'm not pretending to be one. What I am is the person who doesn't hand anything off.

What This Doesn't Mean

It doesn't mean learning React so you can argue about hooks in code review. It doesn't mean you should be shipping production infrastructure at a company that has engineers to do it properly.

It means you can take your own idea all the way to something a stranger can use, without a second person's calendar in the way. That's the whole claim.

The Handoff Was Always the Expensive Part

I spent years in banks and enterprises where the gap between "designed" and "shipped" was measured in quarters. Most of that time wasn't build time. It was translation. Writing specs describing behavior that would have taken ten minutes to demonstrate. Answering questions about edge cases in a document instead of in the product. Watching a decision get quietly reinterpreted three steps downstream and finding out months later.

When you build it yourself, that entire layer disappears. You aren't faster at writing code than an engineer. The gain is that there's nothing to translate.

Building Changes the Design

This is the part people underrate. Designs that look complete in Figma to production with AI routinely fall apart the first time they meet a database.

HerbaLink is a booking platform where herbalist credentials are the gate. On a canvas, that's a verified badge and an upload form. In code, it's a state machine: submitted, under review, approved, rejected, expired, resubmitted. What does the practitioner see in each of those states? Can they take bookings while pending? What happens to a booking that already exists when a credential lapses?

Those aren't implementation details. Those are the product, and you find them by building. Every one of them changed the design.

The same thing happened on the investor loan platform I worked on at a bank, where the goal was replacing Excel as the actual system of record. Three previous attempts had failed. The reason wasn't visual and it wasn't technical. It was that the real workflow only shows itself once something real is in front of the people doing it.

What's Actually Worth Learning

You do not need a computer science education. You need enough to stay oriented while a model does the typing:

• How data is shaped and where it lives, because most product decisions bottom out in the data model.
• What a state is, and how to enumerate all of them for anything you design.
• How to read an error message and a network request, so a broken thing is a puzzle rather than a wall.
• How to run and deploy a project, because a product nobody can reach isn't a product.

That's a matter of weeks, not years, and it's enough to make AI genuinely useful to you instead of confidently unhelpful.

Where This Goes Wrong

The failure mode is obvious once you've hit it. You ship fast, the product works, and six weeks later you're looking at a system you can't reason about because you never actually read half of it.

I've done this. Reading every line isn't the fix. That gives back the speed you just gained. The fix is knowing which parts you have to understand cold: anything touching money, anything touching permissions, anything that runs on a schedule without a human watching. Those I read carefully and often rewrite. The rest can stay a black box until it breaks.

The other failure mode is thinking that because you can build it, you should be the one building it. On a team with engineers, the value of this skill isn't that you take their work. It's that you can AI-powered prototyping in a weekend the argument instead of writing a document about it, and hand over something real when it's time.

The Part That's Uncomfortable

Some design work is going away. Redlines, spec documents, the long tail of handoff artifacts: those existed to move intent across a gap that's closing. If your value was being excellent at producing them, that's worth confronting directly rather than waiting to be told.

What replaces it is more interesting work and more responsibility for the result. When you own it end to end, you can't say the engineers ruined it. It shipped the way you built it.

That's a better trade than it sounds like. It's also not optional much longer.

What that looks like end to end is in the Recast case study.