The process behind every project
How I work with Claude
I'm one person doing the design and the code, so I use Claude as a second set of eyes. It lays out the options, and I pick. Nothing goes live until I say so.
Working alone, I'm the designer, the engineer and the only reviewer. An assistant that builds something and then checks it tends to approve its own work. A session that forgets yesterday's decision will undo it and sound sure about it.
Before and after
Before
I asked for an answer, got one and had to argue with it. My rules only lived in my head, so any new session could break one without anyone noticing.
After
Every decision comes as two to four drawn options with one recommended, and I reply with a letter. Five small AI agents, each with one job, check the work against rules I wrote. None of them can merge a change. Only I can.
How I worked
Research
Every session starts from my written rules
Claude Code, an AI assistant that works inside the code, reads the project's rules and a record of past decisions before it touches anything. I save each decision with its date and my reason, so it's still there months later.
Define
I set how it reports back to me
I wrote Claude a style guide: my request in a box, results on labelled lines, and every question answerable with one letter. In a few seconds I can see what I asked, what got done and what it needs from me. Try answering the question below.
YOU: merge the fix and check it on the phoneDONEMerged. Walked it on the simulator.FOUNDThe date range had no year. Fixed.QUESTION 1 of 1
Tracking links: one line, or a row per link?YOU: aYOU: bNEXT: nothing running.Design
Options before answers
I ask for two to four options drawn side by side on a claude.ai Artifact, a live web page I can click through in light and dark mode. When I can see the real options, I pick faster than I would from a description.
A canvas from the Sollo navigation: five options, one recommendation, one runner-up. Build
One agent, one job
I wrote five agents: a rule guard that checks every change against the rules, a verifier that runs the tests and reports only what failed, a breaker, a walker that uses the app on a phone simulator, and a scribe that records each decision. Quick checks run on a small, cheaper model. Jobs that need judgement get a stronger one.
Test
Try to break it, then use it myself
The breaker plants bugs on purpose to see if the tests catch them. If a test still passes, it was never protecting anything. Then I use the change on a real phone, because that catches what thousands of tests can't.
The turning point
The fork in the road
I stopped asking Claude for an answer and started asking for options, with one marked as its pick.
Why I went this way
Taking the first answer felt faster, but I kept arguing with it. With a recommendation I can overrule, the decision stays mine, and seeing the options together shows me what I would have missed.
The proof
- 70+reviewed code changes merged in eight weeks at Sollo
- 2 to 4drawn options behind every decision
- 5agents I wrote, each with exactly one job
- 11real defects the breaker caught in one night on Centline, before they shipped
What it meansI get the speed of a bigger team and still make every call. At Sollo, a hook (a step that runs automatically) sent every push through the team's review agents, so every change got reviewed the same way, even on a busy day.
