đď¸ This week on How I AI: The internal AI tool thatâs transforming how Stripe designs products
Your weekly listens from How I AI, part of the Lennyâs Podcast Network
Demos not memos: How Stripe built their internal AI prototyping tool | Owen Williams
Listen now on YouTube ⢠Spotify ⢠Apple Podcasts
Brought to you by:
Owen Williams is a design manager at Stripe who built Protodash, an internal AI prototyping tool that lets designers and PMs turn Stripeâs design system into clickable, production-quality prototypes in minutes. What started as a set of Cursor rules and React components has evolved into a full prototyping platform that runs in the browser, supports design reviews, and helps teams move from âmemosâ to working demos. In this episode, Owen shares how Protodash came together, why generic AI design tools often produce âblurple slop,â how PMs became the surprise power users, and what changes when teams can explore real product ideas before writing production code.
Biggest takeaways:
Protodash started as a bundle of Cursor rules, React components, and MCP integrationâthen evolved into a full web-based prototyping platform. The first version was pragmatic: lower the barrier to entry so designers only need to know ânpm run devâ and nothing else. Owen bundled Stripeâs design system components, created an MCP server for Sail, and wrote extensive Cursor rules that taught the AI how to use the project. If a user pastes a Figma link, check the Sail MCP server before writing code. If the MCP server is unavailable, donât just imagine the design system. These rules came from months of iteration and pain points.
The biggest mindset shift for designers is not being afraid of the terminal anymore. Owenâs background is engineering-based, and he always valued hiring technical designers who understood enough of the terminal to be dangerous. Pre-AI, that jump to technical competency was really hard. Now you can just ask Claude, âHow does Git work?â and it tells you. You donât even need to know the commands.
Generic AI prototyping tools donât know your design system, and that creates âblurple slop.â Owen was sitting in design reviews watching designers struggle with tools like v0 that produced uncanny-valley Tailwind prototypes. The nav would be off, fonts wrong, components mismatched. Stripe has a high quality bar and a well-defined design system called Sail, so Owen thought: these tools should know about our design system and construct dashboards from those building blocks reliably. That insight led to Protodash.
An equal number of PMs and designers now use Protodash, and thatâs actually making designer-PM relationships better. Owenâs first reaction when PMs started using it was nervousnessââOh my goodness, PMs designing.â But itâs been thrilling to see PMs build things that look like Stripe in the right way, explore ideas earlier, and communicate better with their designers. Conversations shift from âShould we staff a designer on this project?â to âHereâs the actual work; letâs discuss how to make it better.â PMs can now unblock themselves, test ideas with users earlier, and advocate for design resources with real prototypes instead of abstract arguments.
Prototyping with data in code lets you push the edges of use cases in ways Figma never could. Owen showed a dashboard with almost half a million dollars in gross volumeâbut what about the zero state? What about a company getting one transaction a day? What about different business models: startup versus enterprise? Before, getting all those states into a Figma file was a mess. Now you can just toggle between them. You can design more-interesting things and have them touch reality sooner.
The most valuable internal tools are the ones that match your companyâs specific culture and workflows. Owen points out that staffing internal-tools teams has always been hard, but now you can just build tools that evolve the way you work. Design reviews at Stripe have a tradition of sharing Google Docs with tables for feedbackâso Owen built a design review mode where everyone can comment on the prototype, get an AI-generated summary, and send fixes directly to the AI.
Owenâs rules for working with AI: be specific up front, and as soon as you feel like swearing, slash clear and start again. He has a content background and learned that being specific in the first prompt helps a lot. But the bigger lesson is avoiding sunk-cost fallacy. As someone whoâs built a bunch of stuff, you get attached and think âsurely Iâll get this to work.â Often just throwing it away and starting fresh is faster. If being loud didnât work the first time, reset the context window.
Blog & detailed workflow walkthroughs from this episode:
Stripeâs Owen Williams on Killing âBlurple Slopâ with an Internal Prototyping Studio: http://chatprd.ai/how-i-ai/stripe-owen-williams-on-buildling-internal-prototyping-studio
âł How To Connect a Design System to an AI Code Editor for High Fidelity Prototypes: https://www.chatprd.ai/how-i-ai/workflows/how-to-connect-a-design-system-to-an-ai-code-editor-for-high-fidelity-prototypes
âł Streamline Design Reviews with an AI-Powered Prototyping Studio: https://www.chatprd.ai/how-i-ai/workflows/streamline-design-reviews-with-an-ai-powered-prototyping-studio
âł Build a Personal AI App to Track Purchases and User Manuals: https://www.chatprd.ai/how-i-ai/workflows/build-a-personal-ai-app-to-track-purchases-and-user-manuals




