Have you ever counted the days it takes to get a single product spec approved? You ask a designer for wireframes, run another round of feedback, then go back to an engineer to ask how it would actually look in the product. One Stripe PM coded a tool that collapses that entire waiting period into two minutes—not in Figma, not in some third-party prototyping app, but as a clickable prototype built straight from the company's own internal design system. The tool is called Protodash. For something made by a person whose day job isn't coding, it carries a surprising amount of weight.
Look closely at what actually happened at Stripe
Stripe's Owen Williams built the tool through what's now called "vibe coding": you tell an AI model your intent, shape the code it produces, and revise from there. The finished Protodash takes Stripe's internal design system as input and generates a clickable, interactive prototype in roughly two minutes. That same work used to cost a designer hours—sometimes days.
The point here isn't the speed itself. What Protodash draws on is Stripe's own proprietary design system. Where a typical mockup tool produces a screen that merely looks plausible, this one produces a screen built from the same components as the real product. In other words, a prototype the PM made by hand is visually almost identical to the actual engineering output. The question stakeholders always ask—"but what will it really look like?"—simply disappears.
This case became widely known through Lenny's Newsletter in the first half of 2025. It was framed as a simple productivity hack, but look inside and it's more than that. Two facts sit side by side: a PM can produce a high-quality prototype without a designer's help, and that capability is already in real use inside the company.
There's one reason this is different from before
Until now, when a PM said they "build their own prototypes," it usually meant they'd taken some intro Figma training or could sketch a simple flowchart—and even that came with a fairly long learning curve. Even with a low-fidelity tool like Balsamiq, the question "how does this actually get implemented?" always remained, and you couldn't answer it without a designer and an engineer signing off.
Protodash changes that structure itself. It proves, as a working product, that the role of "making the prototype" doesn't have to belong to a designer. More important still: the person who built the tool wasn't a professional engineer but a PM. The person closest to the problem built the solution.
And that's where a question surfaces. Now that AI has started to substitute for skill and knowledge, the skill of building a prototype and the knowledge of a design system are no longer a PM's bottleneck—AI can handle a good deal of both. So what's left for the PM? The ability to define a problem precisely, the instinct for when and how to use a tool, and the will to go fix an inconvenient reality yourself. That isn't skill, and it isn't knowledge. It's closer to attitude.
If you view competence along three axes—Skill, Knowledge, and Attitude—the first two are exactly what AI tools are replacing fastest. Attitude, on the other hand—the will to face a problem head-on instead of looking away, the readiness to try first even when it isn't perfect—is the one area AI can't replicate. Owen Williams didn't build Protodash because of exceptional coding chops. He built it because the decision came first: "I'm going to solve this annoyance myself."
Of course, reading this as a story about shrinking the designer's role is an oversimplification. What Protodash produces is a prototype for confirmation and alignment. The areas a designer owns—user experience design, decisions about the visual system, accessibility review—sit outside this tool's scope. If anything, designers get freed from low-fidelity review meetings to spend their time on harder decisions. Roles aren't disappearing; each role is moving to a depth AI can't reach.
What does this case mean for Korea's solo founders and product people?
The first question is this. Among the workflows you have right now, is there a "hand it off to someone else" step that you don't actually need?
Many solo founders and solo product people hand off prototypes, proposal mockups, and first drafts of service pages to freelancers or collaborators. If the reason is "because I don't have that skill," it's worth checking whether that premise still holds in 2025. Tools like v0.dev, Bolt, and Lovable already generate component-based UIs with no design experience required. Figma's AI features are advancing fast in the direction of complementing wireframes. A lower technical barrier doesn't mean you're obligated to build it yourself—it means you now have the option to.
The second question has a slightly different grain. The heart of Protodash is that it takes Stripe's design system as input. In other words, the differentiated output only appears when you connect a company's own proprietary assets to the AI tool. If you're a solo founder or a small team, you can ask: "What is my business's design system—the recurring language, tone, structure, and format?" Define that, feed that context to the AI tool, and you'll get far more consistent output. The same goes for a service spec, a proposal, or a content format.
The third thing to examine is how you use AI tools. If you're using AI right now, are you using it as "the person who receives the output," or as "the person who defines the problem and conducts the tool"? The way Owen Williams built Protodash is the latter. It wasn't a simple request like "make me a prototype in two minutes"; he worked out for himself what inputs were needed and what shape of output would solve the problem, then used AI as the execution tool for that design. The difference doesn't stop at output quality—it determines whether you're the person who controls the tool or the person who depends on it.
I won't lay out a list of specific things to try. Instead, just one suggestion: within the next week, take "one deliverable you'd normally have handed to someone" and make it yourself with an AI tool. It's fine if it comes out rough. That experience will make you far more accurate about what to delegate and what to do yourself next time.
What makes this quietly-used, then widely-known tool interesting isn't speed or technology. It's the attitude: "the person who noticed the inconvenience built the solution." Whatever role you're in, the most useful capability in the age of AI still begins with that attitude. You can borrow skill and you can search for knowledge, but saying "I'll give it a try" in front of a problem is something only you can do.
