How Stripe Built an Internal AI Tool That's Eating the Design Process

Lenny Rachitsky's latest interview with Owen Williams from Stripe is the kind of thing every operator should read twice — once for the tool, once for the philosophy.

Stripe built an internal AI tool called Protodash that turns designs into clickable prototypes in about two minutes. No code. No setup. Designers and PMs use it interchangeably. It's restructured how Stripe approaches design reviews.

The interesting part isn't really Protodash. It's what Williams figured out about why most AI design tools suck for real companies.

The "Blurple Slop" problem

Williams's framing for what's wrong with most generic AI design tools is that they produce "blurple slop" — generic AI output that doesn't match anything specific to your brand or design system. Every prompt produces the same kind of bland, generic-looking interface.

Protodash gets around this by teaching the model Stripe's design system specifically — through Cursor rules, MCPs, and integrated components. So when a designer prompts it, the output already looks like Stripe.

The technical guts (in plain English)

• Built on Cursor rules + MCPs (Model Context Protocols) — basically, the model knows the rules of the design system because someone wrote those rules down in a way the AI can read.
• Runs prototypes on dev boxes, not laptops. No local setup needed. Designers don't have to install anything.
• Self-testing prototypes. The tool runs screenshots against the design and grades whether the output matches.
• AI-powered design review annotations. The reviewer can leave structured feedback the system understands.

The unexpected adopters

Williams said the surprise wasn't designers using the tool — it was PMs. Product managers became some of the heaviest users, which fundamentally changed how the design review process at Stripe works.

This is the part that stuck with me. The reason is obvious in hindsight: PMs have always been the bottleneck in design reviews. They want to see the thing. Designers don't always have the time to make the thing. A tool that lets the PM make a clickable version themselves cuts the entire "can I see what this looks like" loop.

"Demos, not memos."

Williams' phrase for the cultural shift this caused. Stripe used to do a lot of design reviews via static docs and screenshots. Protodash made it normal to send a working prototype instead. Once that became the norm, going back to a Figma file felt slow.

What I'd take from this for my own work

A few lessons I'm pulling from this for my agency and SaaS:

1. Internal tools don't need to be polished. Williams said it directly: "Internal tools don't require production-grade polish to drive meaningful transformation." The first version of Protodash didn't ship to customers. It just had to work for the team.

Most of my clients hesitate to build internal AI tools because they think it has to be a real product. It doesn't. It has to be useful for one workflow. That's the whole bar.

2. Teach the model your specifics. Generic prompts produce generic output. Stripe's edge is that they encoded their design system into the AI. For my work, that means feeding Claude my actual writing samples, my actual past pages, my actual brand voice — instead of starting fresh every time.

3. Build for the bottleneck, not the user. Stripe optimized for designers. Then PMs flooded in. The lesson: the user you're solving for is rarely the user that ends up using the tool the most. Build for the workflow, not the role.

What this means for small businesses

You don't need a Stripe-sized team to do a version of this. Even a single founder can:

• Build a Claude project trained on their brand voice and design samples.
• Use Cursor or similar tools to encode their stack rules.
• Treat "prototypes over docs" as a personal habit — show, don't write.

You won't get Protodash. You'll get something smaller and weirder. That's fine. The goal is the workflow, not the product.

The Bottom Line

Protodash isn't impressive because it's a fancy tool — it's impressive because it shows what happens when a team teaches AI their actual context instead of using it generically. Every business has a design review, a content review, or a customer-facing review process that could benefit from "demos, not memos." Build the smallest version this week. The polish comes later.