Let's be honest. The vast majority of us product designers have been stuck in the gap between what we design and what gets built. Our work has depended on detailed mocks and specs with redlines, talented frontend partners, and sheer persistence to make sure the end result came out right.
Not anymore.
This is the story of how and why we built an AI-powered prototyping environment at Faire called Playground that helps anyone turn ideas into reality. It lets non-technical people design in code, without any risk of breaking the real product. I'll walk you through how we went about it and I'm confident you can build one at your company too.
It's still early, but 50+ contributors have built nearly 200 prototypes, most with zero coding experience. Playground isn't the end state, but it's how we started closing the gap between design vision and execution.
How I got here
I've spent nearly 15 years in tech at companies like Okta, Dapper Labs and Coinbase. I've worked as a designer and manager, and I even started my own company. But I wouldn't consider myself technical by any means (though my friends and family outside the tech world wouldn't believe it, given all the requests to fix their routers). I've never written code or done any frontend work in my life.
At my HR startup Otti, I unlocked something that changed my approach to the work. Lovable, Bolt, and V0 seemed to pop up overnight, promoted as coding tools for non-coders. I had a side navigation concept in my head I wanted to see. Instead of mocking it up in Figma like I did for every other feature, I described it in V0 and sent the team a link. Everyone was kind of in shock, and honestly, so was I. I'd built something in code, something the team could actually play with. After Otti shut down, I couldn't stop. I built an iOS sports app with Claude Code, something I'd wanted to make forever. Nothing was stopping me from turning ideas into reality, besides tokens.
I joined Faire in September 2025, excited to work with an incredibly talented design team and adamant about immediately figuring out how to integrate this new way of designing into my workflow. Reality struck quickly, as using these tools at a company with a sizable production codebase is a very different beast than tinkering on side projects.
On one of my first features at Faire, instead of opening Figma, I thought, what if I just tried to prototype this in code? The team used Cursor so I hopped into the frontend repo and immediately hit walls. I couldn't get local running. The remote dev boxes were confusing. The codebase was complicated, full of business logic. None of that was Faire's fault. The codebase wasn't built for people like me, and I had no idea what I was doing. And yet I knew there had to be a way. I'd just used V0 to build something in code without writing any. There was no going back.
The moment it clicked
Turns out I wasn't the only one. One effort led by Austin Dick focused on helping designers land small, safe UI changes directly in the codebase, and was really influential in getting the team over the initial hump of using Cursor. Ryan Lee also had been playing around and messaged me on November 3rd saying:
5:59 PM: "yo! what's the latest on the cursor environment? i keep wondering now if we should just create some lightweight local version for quick prototyping."
Coincidentally, at that exact moment, I was in the audience at an event in NYC called Building With Cursor, featuring Ryo Lu (Cursor), Jin Park (Notion), and Catherine Wang (Ramp) discussing how to unlock designers so they could use these tools. Everyone seemed to hover around a similar solution: building a prototype playground, disconnected from the codebase, lightweight and easy for non-technical designers to play in. Cursor even named theirs Baby Cursor! Things were happening all around us. We had to figure this out at Faire.
Ryan had started building out templates locally, core components like the global nav and footer, things you could snap together to prototype quickly without touching production. He had deep institutional knowledge of the product and trust as a long time leader within the design organization. Gabe Kelley, who leads Design Systems at Faire, jumped in and brought the most technical depth of the three of us, thinking through everything with a systems-level approach. That's when things really took off.
What we built
Playground is an experimental space where anyone can rapidly explore ideas and build what looks and feels close to our actual product. It's decoupled from live data, experiments, and business logic. The goal isn't to ship production-ready code. It's to explore, feel, validate, and communicate ideas quickly and clearly. No dependencies, no risk of breaking anything. Just a place to build.
There's no one right way to use it, but there are a lot of ways in. You could feed it a PRD for context. Pass it a Figma file for visual reference. Even point it at what's live in the actual product. You describe what you have in mind in plain language and it gets built in code.
The first version is never right. We think of it like clay. You start with a block, it doesn't look like much, but you begin to shape it. Each pass gets closer. This is where designers in particular can soar, leveraging their unique point of view and vision to make it come to life. And because it's code, what you're shaping is interactive. When you send someone a link, they don't see a slideshow of screens. They feel what you're designing, and it's closer to what our users will actually experience.
First, Ryan created a repo and signed up for Vercel. I bought a domain, theplayground.design, because us designers obviously need something fun. No offense, free Vercel URL. Two weeks later we moved it under Faire's org. It had a name, a Getting Started guide, and a URL anyone could use.
To make prototypes feel like the real product, we needed our design system. But Slate, Faire's design system, was deeply integrated into our production infrastructure. Like most mature design systems, it wasn't yet built to be consumed outside of that environment. So we built a workaround. At first it was basic. Screenshots of the real product and language to describe what we wanted, enough to make things feel real without touching production code. Then Gabe found a better path. He'd been building Slate in Figma with one-to-one parity, so he could use Figma's MCP to generate components that looked and felt like Faire automatically. We called this FauxDS, a fake design system that felt real. It meant any designer could spin up a prototype that looked like Faire's actual product in minutes, not days. Suddenly prototypes felt tangible but nothing in our actual code base could break.
It didn't matter what tool you used. Claude Code, Cursor, Figma Make. The day we added Figma Make support was the day it stopped being "for people who code" and became "for people who prototype." The tool doesn't matter. Building is the point. The prototype code may be disposable, but the thinking it captures is not. Not every prototype becomes production code, and most won't. But every one of them moves our thinking forward. The real velocity gains come from removing the gap between thinking and building.
But speed without quality is AI slop. Quality without speed is the old world. That tension is why FauxDS mattered so much. It meant anyone could move fast and still make something that felt like the real product.
While the Playground's obvious value is allowing people to make things, it's really the infrastructure around it that turns it into something that is valuable to the full team. A feed on the homepage shows every prototype side by side, so you can see what everyone else is making the moment it merges. A Getting Started guide walks you through setup from scratch. A Playbook covers the day-to-day workflow once you're up and running. Each piece reinforces the others. The docs get you in, the feed keeps you inspired, and FauxDS makes what you build feel worth sharing.
And because we built the tool ourselves, we could shape it as we went. Every friction point became a fix. Every onboarding session improved the guide. We weren't waiting on someone else to make our environment better.
What it unlocked
All of our Design team, plus Creative, UXR, Product Management, and even some engineers started building in Playground.
By December 12th, 10 days after the repo moved to Faire's org, our Head of Design was submitting pull requests. Go Tim! Not reviewing them. Building. The first two designers to use this were Cristi Wallace and Kevin Lai, both intrigued but firmly on the non-technical end of the spectrum. Perfect test case for how accessible this really was outside the three of us. They were genuinely afraid, said so out loud, and then they started building. That was the moment I thought, oh my god, this is working.
What followed was brute force. Onboarding most designers one at a time, making sure they felt comfortable. Screen share, walking them through terminals and SSH keys and Git for the first time. After every session, we'd take notes on where they got stuck, feed it back into the Getting Started guide, and the next person would have a smoother experience. The guide was updated 11 times in three months. 20+ sessions, most of them one-on-one.
Then the product managers started showing up. Then user researchers. Then the creative team, people who had genuinely never opened a terminal in their lives. We walked them through installing Homebrew. Generating SSH keys. Cloning a repo. A week later they were submitting pull requests. Then our CPO submitted one. Go Sanjay!
And then something I didn't anticipate. I took a prototype I'd built in Playground and opened up the production codebase side by side. Asked Claude Code to describe a component's styling, copied that description over to the frontend repo, and it just worked. The production version looked like what I'd designed. I collaborated with my engineer to review and refine it, and together we got it over the line. That workflow, Playground to production, closed the gap that had existed between design and engineering for as long as I've been doing this work.
The whole thing snowballed. One person to three to 10 to 50+. Over 200 prototypes. Nearly all of our Design team, plus Creative, UXR, Product Management, and even some engineers. The feed became this living thing where people could see what everyone else was building and riff on each other's work. That visibility turned out to be one of the most important parts of the whole system. When people can see what others are making, they learn faster, they get inspired, and the bar quietly rises across the whole team.
Where this is going
Nobody really asked us to do any of this. There was no project brief, no OKR, no allocated time. We were all doing our regular product work and finding time for Playground wherever we could. We saw something worth doing and it was fun. It became addicting, chasing it down and enjoying the ride.
Three months in, Playground officially migrated into our frontend codebase. What started as a side project became a real priority with engineers assigned, a daily standup formed and real momentum. This is no longer a side quest. It's an internal product.
I believe that Playground is a bridge, not a destination. The dream is that it becomes unnecessary. That designers can work directly in the codebase their users actually touch. For a startup with a small codebase, that's probably already possible today. For a big company with years of accumulated complexity, the gap is still real. Playground is how you close it. And if we do this right, it's the bridge we get to tear down.
Want to build out your own Playground at your company or learn from others who already are? Send me a note. I'd love to hear from you.