A pipeline built for speed

Three fast loops, in three different places

Everyone on the spinout was working with AI agents. Engineering scoped features into tickets precise enough for agents to build. Product drafted the requirements. And I ran my own loop: several agents at a time, ahead of the build cycle, exploring possible solutions to discuss and refine with product and engineering.

Design was well equipped. I'd built out an elaborate design system and component library, so any prototype could be spun up quickly from a replica of the live product, along with domain docs: house rules for how prototypes should be built, how they behave, and how they're promoted or retired.

The trouble was where everything lived. Claude Design, novel and interesting when I started, didn't connect cleanly to Storybook, where the component library lived, or to Claude Code, which engineering used, so I ended up vibecoding my own tooling to suit how I worked. Meanwhile, product drafted requirements in Google Docs, which were later adopted into the codebase, sometimes leapfrogging or contradicting the rules set out in the design docs.

So there were always translation layers between the product's domain docs, the design specs and the build plans, and each one was another chance to fall out of sync. None of this was ignorance or negligence. We were building a product quickly, while working out how we each worked, with tools that were new to all of us.

Bring the loops together, without slowing down

Each of us had found a groove. The job was to design tooling that brought them together, so a requirement, a design and a build plan could no longer disagree, and to pick the right moment to stop and rebuild.

One repo, one pipeline

Pause, reflect, rebuild

When the time made sense to pause, we did. Product, design and engineering rebuilt how we worked around one monorepo, with the product's docs, the design system, the prototypes and the code in the same place. It took a matter of days, and we moved forward with far more efficiency after that.

Start from product's brief

Product's docs became the brief for the design process. Each design showed how a requirement was realised, or called out a point to spar on, with its options. Anything outstanding was flagged and settled before the project could move on, so contradictions and discrepancies were caught before they reached a build.

Prototypes that mirror the live product

I built my own design tooling and seed data, so I could spin up several solution options quickly. Interactive prototypes mirrored the live product exactly, so product and design could compare options and iterate fast, without surprises like "how would this edge case behave?" The same tooling highlighted anything new: components and behaviours not yet in the product were marked, and became specific instructions for the next stage.

None of it needed the command line. Engineering set up the first prototype viewer, and I turned it into a studio: a gallery of explorations, previews at phone, tablet, old-phone and desktop sizes, and one screen to update a branch, run the design checks and ship a pull request, each with its own preview link for reviewers.

Curate the building blocks

I was empowered to curate the component library, adding new elements and organisms with their styling and behaviours built in. With the building blocks ready, engineering and their agents could pick them up for each build, and I could check in small fixes myself: copy, styling or behaviour.

Let the code decide how a design ships

Promoting an exploration starts with one question: does the app already have everything this needs? If it only rearranges, restyles or relabels what's there, the design goes straight into the product in one change. If it needs new data, actions or rules, it goes into System as "awaiting build" with a ticket drafted for engineering. Nobody argues about how finished a design feels; the code decides.

Agree the plan before the build

By the time a feature reached engineering, the documentation built up along the way let their agents draft a build strategy for everyone to review, pick apart and feed back on, before anything was built. End to end, a feature moved like this, each step an AI-assisted session with a person making the calls:

1. BriefProduct's docs set out one problem, its outcomes and its requirements.
2. ExploreI prototype options from real components, showing how each requirement is met and marking what's open.
3. SettleOpen questions are sparred on and settled before anything moves on.
4. PlanEngineering's agents draft a build strategy from everything upstream, for the team to review and pick apart.
5. Build and validateAgents build it; a person tests the whole and merges.

For an average feature, all of this took about a day, from concept to build.

Design at the speed of the code

• 4 daysto rebuild how product, design and engineering worked, around one monorepo.
• Minutesfrom an idea to a fully interactive preview link, ready for the team or a customer to explore.
• 1 to 3 daysfrom a feature being prioritised to a solution signed off by everyone.
• 34changes shipped in my last two weeks alone, across production UI, tooling and explorations.

As the team put it, and I agree: rather than spending time and frustration aligning our tools on either side of a fence, we gave ourselves time back to strategise on solutions and directions.