For an indie developer, the heaviest moment is often the very first step of building a screen from nothing. You know what you want, yet just thinking about choosing colors, laying out the screen, and arranging components is enough to push the work to tomorrow. As someone running Dolice Labs, a set of four blogs, I have stalled right at that threshold more times than I can count.
What recently lightened that block is a way of working that moves between Claude Design and Claude Code. Let Claude Design handle design divergence and let Claude Code tighten the implementation. Once the roles are clearly split, that first step gets startlingly lighter. Here I lay out the whole round trip in one view.
First, assign "diverge" and "converge" to different tools
The core of this approach is handing two tasks of different character to two different tools. Widening a design's direction and locking an implementation into one shape demand completely different modes of thinking.
- Claude Design (diverge) — produce the direction of color, layout, and components as multiple working prototypes
- Claude Code (converge) — turn the prototype into production that runs on real data: tidy the internals, design the data, set up CI, fine-tune on a real device
Fuss over implementation detail while diverging and you freeze; keep second-guessing the design while converging and you never finish. Simply splitting the tools untangles that cross-talk on its own. By my own feel, this division was the single biggest win.
Claude Design "asks before it builds"
What is interesting about Claude Design is that it does not start building right away — it first returns multiple-choice questions. Who is it for, how interactive should it be, how many options to line up. It is a tap-to-answer form, and your premises snap into alignment all at once.
This was faster than writing a spec, and it pinned down requirements I had not even managed to put into words. "Just build something" lets the other side fill in your premises for you, but being asked first lets you enter the prototype with a shared understanding. Answering those first questions carefully is the shortcut to less rework later.
Line up several options and decide by touching them
Claude Design does not narrow to one direction; it lines up multiple options as working prototypes. Because you can compare the real things, judgments like "this is too information-dense" or "the whitespace feels good but the scroll runs long" come far faster than reading a written spec.
And it does not end at a first draft — the strength of a prototype is that you can keep fixing it while you touch it. Even interactions, like switching the display when you click an element, can be pinned down at this stage. You can spin the "touch it, and revert if it is wrong" loop fast, so deciding the direction and the early build become one continuous flow.
Carry it into Claude Code and make it production-ready
Once the direction is set, carry it into Claude Code and tighten the detail. Feed it real data, auto-update via CI, keep it from breaking on mobile — only then does it become a tool you use daily.
What helps here is the stance of starting from "make what already exists work correctly" before adding flashy new features. Fold away the prototype's branches to focus on the main line; fix the text that overflows at an in-between screen width. Beginning production from these humble moves keeps the foundation from cracking. When I build tooling around my blogs, I too start by cleaning up these loose ends.
Bridge the round trip with Link Local code and Send to
If you are going to move between two tools, friction in passing files will kill the habit. At first I did it by hand with imports and ZIP exports, and minding "which one is newest" was a quiet tax.
Two mechanisms ease this. To read your local repo into Claude Design, "Link Local code" lets you point directly at a local directory and read the latest files without going through GitHub. The other way — writing canvas edits back to the repo — runs through "Send to...", where you pick your local coding agent as the destination and it hands you an import prompt. The actual sync is a pull on the Claude Code side, so you can review the diff before committing each import, and it rides on your usual development loop.
Where to start
Trying this round trip on a large project right away will exhaust you before you find the rhythm. I recommend picking one small, tightly scoped theme and doing a full lap: decide the direction in Claude Design, then make it production-ready in Claude Code.
One lap, and the feel of handing diverge and converge to separate tools settles into your body. I myself caught the rhythm on a small dashboard-like subject, then widened the scale from there. In the follow-up, I dig into the production work that makes this round trip steadier — single-sourcing, CI auto-updates, and auto-generating social share images — with implementation included. Start with one small lap.