The loop I teach designers to build real things

Most designers can picture a product but stall at building one. What I teach at Designers Who Build isn't code, it's a repeatable loop: plan the work into testable steps, build by choosing from options, keep the judgment yours, and ship to a live URL. Learn it once, run it forever.
repeatable loop plan, build, verify, ship testable steps small pieces you can check judgment the calls only you can make live URL a real link anyone can open

You can see the product in your head. The screens, the flow, the little details you'd sweat over. You just can't build it. That gap, between picturing a thing and shipping a thing, is where most designers stop. Designers Who Build exists to close it. And the way we close it is a loop.

Four moves. Plan, build, verify, ship. Then you do it again. That's the whole method. No terminal wizardry, no computer-science degree. You direct the work, the AI does the typing.

01
Plan
A memory and a set of testable steps
02
Build
Ask for three, pick one, record it
03
Verify
You decide when it's good enough
04
Ship
Push, wait a minute, live URL
then run it again
The whole method, on one line.

The one rule underneath all of it: you don't write the code, you direct it. The AI can type faster than any of us and never gets tired. What it can't do is decide what's worth building, or when it's good. That part stays yours. It always was.

Plan

Every build starts blank. The AI doesn't know your project, your stack, or why you picked the blue button yesterday. So the first move is to give it two things: a memory, and a plan.

The memory is a single file the AI reads at the start of every session. Your project in a paragraph: what it does, what it's built on, the decisions you've already made. Every AI tool has one of these now, it just has a different name (CLAUDE.md, GEMINI.md, AGENTS.md). Same idea: a brain that survives after the conversation is gone.

Then the plan. A plan here isn't a document nobody reads. It's the work broken into phases, and each phase into small steps you can actually test. Not "build the app." More like: phase one, get a form on the screen. Phase two, save what someone types. Every phase ends in a check you can see with your own eyes.

docs/plan.md
Phase 1 · Skeleton✓ form on screen
create the project
add a text box and a button
Phase 2 · Store it✓ it saves
save what someone types
show it back to them
Phase 3 · The AI does the worknext
Phase 4 · Polish and shiplater
A plan is just phases, steps, and a check at the end of each.

The line I repeat all day: plans survive, conversations don't. Save the plan to a file, and tomorrow-you, or a brand-new session, picks up exactly where you left off instead of re-explaining everything from scratch.

Build

This is the part designers already know, just in a new medium. You don't describe the interface in a paragraph and hope. You sketch it, even roughly, so the idea is clear in your own head first. Then you ask for options.

Never ask for one. Ask for three. Trying things is basically free now, so explore wide and then choose, exactly like you would in Figma. Pick the one that's right, delete the other two, and tell the AI to remember why you chose it.

Option 1
✓ keep
Option 2
Option 3
Three takes on the same screen. Keep one, drop the rest.

That last step matters more than it looks. If you don't record the decision, next week you (or the AI) will re-argue it from scratch. Say "going with this one, save it" and the choice stays decided. Today's decisions should stay decided.

Verify

Here's the step people skip, and it's the one that separates a demo from a product.

After every small step, take a quick look. Does it run? Click it once. Move on. After every phase, do a real review: click everything, read what changed, make sure it actually holds together. Step checks catch typos. Phase checks catch the logic mistakes that quietly pile up when you're not looking.

And the part that's yours alone: you decide when it's good enough. Is the empty state handled? Does the error message sound like a person or a machine? Is the spacing right? The AI will happily call something done. Whether it's actually good is your call. That was always the job, it just used to be buried under all the typing.

Ship

Most people never reach this step, because "deploy" sounds like a project of its own. It isn't anymore.

You save your work and push it up. About a minute later, it's live on a real web address. No servers to configure, no scripts to run. And if the word "branch" ever scares you, it's the same thing as "Make a Copy" in Google Docs: a safe lane to try something without touching what already works.

>_
Push it
from your laptop
It builds
automatically
yoursite.in
live in ~60 seconds
Push, wait about a minute, and it's on a real URL.

Then the part everyone forgets: send it to one person. A friend, on WhatsApp. Ask them to try it for two minutes and watch what they tap first. A live link nobody opens is the same as no link at all.

But doesn't the AI just do this itself now?

Fair question. There are agents that take the whole loop off your hands: you give them a goal, and they plan, build, verify, and ship on their own. So why learn to direct it?

Because autonomy owns the how, not the what. An agent can type the code and wire up the deploy. It still can't decide what's worth building, or whether the result is actually good for a real person. Hand it a goal and accept whatever comes back, and you've just handed off again, to a different black box.

You decide
what's worth building
when it's actually good
hand it a goal, and it takes over
The AI runs the loop
goal: "a feedback form" Plan Build Verify Ship
Hand it a goal and it runs the whole loop. The two calls at the ends still stay yours.

So the agents don't retire the loop. They move it up a level: less typing, more deciding. The boring parts get nearly free, which means you spend more of your time on the one part a designer can't outsource, the judgment.

Then again

You go back to the top. Plan, build, verify, ship, again. The first time around it takes a day. The tenth time it's a Tuesday afternoon.

Notice what's not in that loop: writing code. The skill I'm actually teaching isn't a language or a framework, both of which will be different in a year. It's the rhythm, knowing when to plan, when to generate, when to stop and judge, when to ship. The rhythm is the part that transfers.

The tool will keep changing. The loop won't.

So if you're a designer who's been waiting for permission to build the thing instead of handing it off, this is the permission. Learn the loop once. The next tool is just a detail.

Plan, build, verify, ship. Then again.

Let's connect

Building something interesting? Want to learn to build with AI? Always happy to chat about design, products, and the messy middle of shipping.