Prototyping vs. Product: Understanding the Difference
I Built a Figma Plugin in 3 Days. Then I Tried to Publish It.
Three days. That’s how long it took me to vibe-code a working Figma plugin that uses Langchain.
It worked perfectly. I could run it, test it, use it.
So I pushed the code to GitHub and started going through the publishing instructions.
That’s when reality hit.
The “Works on My Machine” Problem
As I read through Figma’s step-by-step guide, I realized something: I needed to run a dev server for the plugin to work.
Which meant anyone else who wanted to use it would need to:
Clone my repo
Install dependencies
Run their own dev server
Not exactly plug-and-play.
But I’m learning, right? So I asked Warp (my AI terminal) a simple question: “Can I publish this extension?”
Here’s what came back:
Critical security issues: - Hardcoded localhost API URL - Network access configuration problems - Missing production infrastructure (no deployed backend) - No API authentication or authorization - API key security risks
I hadn’t built a product. I’d built a prototype that only worked in my development environment.
Then I Gave Someone Else the Same Advice
A few days later, I saw a LinkedIn post asking about vibe coding sessions with Figma Make.
For context: Figma Make uses Claude 3.7 Sonnet and is basically a vibe coding platform built into Figma. The person noticed that in most vibe coding sessions, people from the production world weren’t really mentioning Figma.
I commented: “That’s because Figma Make ≠ production code. It’s best for making coded prototypes.”
They asked the obvious follow-up: “What would you recommend as next steps? Would it work if I try to push the codes to GitHub and have an IDE like Cursor pull it for closer to proper production?”
My response: “It’s not very straightforward but in essence yes. But you need to know what to check and tell Cursor to change/add/rewrite the code to be more production ready in terms of security, scalability, and code quality.”
I gave that advice confidently.
Having just made the exact same mistake myself days earlier.
The Framework That Finally Clicked
Here’s what I’ve learned: Vibe coding democratized prototyping, not product building.
And there’s a massive difference between the two.
A prototype’s purpose is to LEARN: - Is this technically feasible to build? - Does this provide significant value to people? - Would anyone actually use this? - What features matter most?
A product’s purpose is to OPTIMIZE something that’s already been proven: - Maximize the value delivered to customers - Maximize value capture (revenue, retention, engagement) - Ensure reliability and security at scale - Maintain longevity throughout its lifecycle
The key word: proven.
You prototype to prove something works. You build a product to optimize what you’ve already proven.
The intent changes everything.
Prototypes are meant to be quick and dirty. They’re meant to be thrown away and iterated on.
Products are meant to last. They need to handle edge cases, scale with users, and work reliably for months or years.
Why AI Can’t Build Production-Ready Products Yet
I’ve been thinking about why vibe coding struggles here.
The answer: Most people don’t think like engineers. And neither do current LLMs.
Engineers are trained to ask: - What happens if this breaks? - How does this scale to 10,000 users? - What security vulnerabilities exist? - What if the user is offline? - What if someone tries to exploit this?
When I asked my AI to check if the code was production-ready, it gave me a list of issues. But I had to know to ask. I had to know what “production-ready” even meant.
Current LLMs in 2025 aren’t great at defensive thinking. Research from August 2025 shows that over 40% of AI-generated code contains security flaws. Only 55% passes basic security checks.
Why? These models are trained on public code from GitHub, Stack Overflow, and documentation. Good code AND bad code. Secure patterns AND insecure patterns.
They learn from everything, including the vulnerabilities.
What Actually Happened to My Plugin
Right now? It’s still a prototype. And I’m okay with that.
I’m using it to answer questions: - Does this workflow actually help me?
- What would make this more useful? - Is this worth investing more time in?
If the answer to those questions is “yes,” THEN I’ll make it production-ready. Either by learning what I need to know, or by bringing in someone who understands production architecture.
But I’m not confused anymore about what I built.
The Lesson for Founders
If you’ve vibe-coded something and it works, congratulations. You’ve just prototyped faster than anyone could have 5 years ago.
But ask yourself: What was the purpose of building this?
If the answer is “to learn if people want this,” you’re using vibe coding correctly. Test it. Break it. Throw it away if needed.
If the answer is “to launch a business,” you have more work ahead.
You need to know (or find someone who knows): - How to secure your code - How to set up proper hosting - How to handle errors and edge cases - How to scale beyond your first 10 users - How to separate free and paid features
Can AI help? Yes—if you know what to ask for. And if you can verify the output is actually secure.
The biggest beneficiaries of vibe coding right now are semi-technical founders. People who understand enough to know what production-readiness requires, even if they can’t build it all themselves.
What I’m Doing Differently
My approach: Learn enough about deploying to production that I can use GenAI to help me vibe code the infrastructure.
But first, I need to understand: - What questions to ask - What to check for - What “good” looks like
Vibe coding gave us superpowers for prototyping. That’s incredible.
But it didn’t eliminate the gap between “it works on my machine” and “it’s ready for customers.”
If there’s one thing you take away from this: Know which one you’re building—prototype or product. Be honest about what comes next.