Stripe’s Owen Williams on Killing ‘Blurple Slop’ with an Internal Prototyping Studio

Stripe Design Manager Owen Williams got tired of AI prototypes that looked almost right until you noticed the fonts, navigation, spacing, and interactions were subtly off. The fix was not a better prompt. It was a constrained environment that gave the model Stripe’s actual design system, rules, and infrastructure to work with. See Streamline Design Reviews with an AI-Powered Prototyping Studio. See How to Connect a Design System to an AI Code Editor for High-Fidelity Prototypes.

In this episode of How I AI, Owen walks through how an internal prototype kit evolved into ProtoDash Studio, a browser-based workspace for building realistic Stripe dashboards and workflows. General-purpose generators could produce plausible interfaces, but they still drifted toward generic defaults instead of Stripe’s product language and review standards.

The progression is what makes the system interesting. Owen started with a local React starter kit, added Sail design-system components and MCP access, moved everything onto hosted dev boxes, then layered in browser prompting, visual annotation, AI-assisted review, and reusable prototype variants. The result is less like a single AI tool and more like a custom operating environment for Stripe’s design process.

Ground the model in Stripe’s actual UI system

Owen called the generic result "blurple slop": interfaces that looked convincing at first glance but still felt wrong in review. Navigation patterns were off. Fonts and spacing drifted. Components behaved differently from production Stripe. Sail, Stripe’s internal design system, was structured and predictable enough that the model could use it as a reliable source of truth instead of improvising.

The original stack

The first version was intentionally narrow. Owen wanted designers to get from zero to a working prototype with little more than npm run dev, without needing deep React or infrastructure knowledge.

The starter environment bundled together a few opinionated pieces:

• A React shell with Stripe dashboard navigation and routing already configured.
• Sail design-system components so generated interfaces inherited Stripe styling and interaction patterns.
• An internal Sail MCP server the agent could query before generating UI.
• Cursor rules that taught the model how the environment should behave and what order to follow.

At first, designers ran the kit locally. Later, the whole workflow moved onto Stripe’s internal dev-box infrastructure. A designer could open an internal URL, wait roughly two minutes for a fully configured environment, connect through Cursor, and immediately share a live preview. That shift mattered because the prototype stopped being a local experiment and became a reviewable artifact anyone could click through in a meeting.

Teach the agent when to trust the system

The Cursor rules handled both workflow sequencing and failure modes. If someone pasted a Figma link, the model was instructed to query Sail before writing code. If the MCP server failed, the model was supposed to report the issue instead of inventing replacement components. Owen said large models will confidently fabricate an entire design system if you let them, so the rules existed partly to keep the prototype anchored to reality.

These rules would tell the AI things like, "if a user pastes a Figma link, you should check the Sail MCP server before writing any code." It also included guardrails, like what to do if the MCP server is unavailable, because LLMs will happily hallucinate an entire design system if you let them. These rules were the secret sauce that ensured the output was 90% of the way there, leaving the final 10% for the designer’s craft and refinement.

That grounding consistently got prototypes most of the way to Stripe quality before a designer refined the details. It also unlocked something harder to do in static mockups: realistic data states. Teams could quickly generate versions for enterprise customers, startups, empty dashboards, crowded dashboards, localization edge cases, and messy datasets without manually rebuilding every state in Figma.

Turn the prototype into a browser workspace

ProtoDash Studio added a browser layer on top of the original coding workflow. Instead of opening Cursor for every experiment, designers and PMs could browse existing prototypes, remix them, prompt changes directly in the browser, and share live environments from a single interface.

Generate and revise dashboards in place

The studio runs inside a dev box and embeds both the rendered prototype and the model interface side by side. Owen described it as trying to build something closer to a highly opinionated internal version of tools like v0, but tied directly to Stripe’s infrastructure and review culture.

During the demo, Owen entered short natural-language requests directly into the browser instead of switching back to Cursor. The model generated dashboard variants, rewired layouts, and adjusted charts while the prototype remained live and interactive.

I want to add a new variant of my prototype where the stacked chart, it's a line chart.

One useful detail was the self-checking loop. After generating a screen, the system could capture screenshots of its own output, inspect the rendered result, and continue iterating if something looked broken. Owen showed the prototype visibly testing itself in the browser during generation.

Owen and I also generated a new Black Friday and Cyber Monday themed dashboard from a single prompt. The request was intentionally vague: live sales data, charts, and trending products for a pet store. The goal was less about perfect design and more about seeing how much structure the system could assemble on its own.

build a BFCM dashboard for a pet store showing live sales on a chart at the top of the page. A ticker with the latest sales. And trending products. Make sure the data is realistic and real time.

The first pass came back quickly with charts, ticker-style sales updates, and Stripe-style navigation already wired together. Some of the proportions were wrong, especially an oversized chart that dominated the page, but the interactions and overall structure were immediately reviewable. That became a recurring theme throughout the episode: the prototype did not need to be production-perfect to become useful much earlier in the design process.

Give feedback directly on the canvas

ProtoDash Studio also added an annotate-for-AI mode. Instead of describing selectors or hunting through generated code, Owen could click directly on a chart, table, or tooltip and attach feedback to that specific element.

I don't want to lose my mind in cursor being like 'the element with class name 82 F, please fix this.' Being able to just select something and give the feedback is really exciting.

In the demo, Owen selected the oversized chart and simply told the system it should be narrower. The model updated the layout without requiring any CSS selector lookup or manual code editing. I compared the workflow to newer visual prompting tools, but the difference here was that the annotations operated inside Stripe’s actual component system and review environment.

Design Review Mode extended the same idea to team feedback. Instead of dropping screenshots into documents, reviewers commented directly on the interactive prototype. The system could summarize comments, queue suggested fixes as agent tasks, and generate follow-up updates, but designers still reviewed and approved the changes themselves. Owen framed this less as replacing review and more as removing the administrative cleanup that normally follows a design session.

A parental-leave side project for receipts and warranties

Outside Stripe, Owen used the same workflow style during parental leave to build a personal app for tracking household purchases, warranties, manuals, and receipts. The project started from a familiar frustration: expensive items break years later, and nobody remembers where the receipt or warranty information went. You can follow the full implementation in Build a Personal AI App to Track Purchases and User Manuals. See Build a Personal AI App to Track Purchases and User Manuals.

The app automates a surprisingly tedious workflow:

1. 1. Add an expensive purchase such as a bicycle or television.
2. 2. Photograph the receipt and the product itself.
3. 3. Extract details like the serial number, purchase date, and price.
4. 4. Find and save the matching product manual automatically.

The resulting record makes warranty claims, maintenance, and resale easier later on. Owen and I immediately started brainstorming extensions like expiration reminders and resale prompts for kids’ gear. Even in this smaller example, the pattern matched ProtoDash: start with a narrow but annoying workflow, then automate the repetitive coordination around it while keeping human verification in the loop.

What actually changed inside Stripe

ProtoDash worked because it was opinionated. It assumed Stripe’s components, Stripe’s infrastructure, Stripe’s review habits, and Stripe’s quality bar. Owen repeatedly emphasized that the goal was not to replace every design or coding tool. The value came from reducing setup friction and keeping the model grounded in the same environment designers and engineers already used.

The biggest shift was cultural. Teams moved from static mockups and slide decks toward live prototypes that could be clicked, remixed, tested with data, and handed directly to engineering. PMs became some of the heaviest users because they could finally express ideas visually without waiting for fully staffed design support. The workflow is especially worth copying if your company already has a mature design system and a repetitive review process that AI can plug into. The hard part still requires human judgment: deciding what deserves refinement, catching subtle quality issues, and shaping experiences that go beyond assembling approved components.