There’s a gap between having a product idea and actually showing it to someone. Product managers write briefs in Linear, describe features in Slack threads, maybe sketch wireframes. All text. All static. And then you hope everyone reads it, imagines the same thing you’re imagining, and feels as excited as you do about a concept that only exists in your head.
That rarely happens.
At Upsun, we’ve been closing that gap: PMs talk to an AI coding assistant, generate a working prototype, push a branch, and share a live URL. The whole thing takes an afternoon. It doesn’t replace designers doing proper designs in Figma, and it doesn’t replace engineers writing production code. But it fills a hole in the early ideation stage that no amount of well-written tickets can fill.
The gap between idea and validation
There’s a dead zone at the very beginning of any product idea. You have a rough concept and you need to communicate it to people who weren’t inside your head when you thought of it. A Linear project or a Slack thread doesn’t have the same power of influence as seeing an idea in an interface and playing with it directly.
Product managers aren’t designers and they aren’t developers either. They have ideas and deep knowledge of the problems and needs of the customers, but lack the traditional tools to make those ideas tangible quickly. Talking to an AI coding assistant changes that equation. You tell Claude what you want to test, iterate on a rough spec through conversation, and end up with something interactive that people can click on and react to. It’s faster than opening a Figma file, and considerably faster than writing a spec detailed enough for someone else to build from.
A prototype is worth a thousand briefs
The code quality is irrelevant. This is vibe coding in the truest sense: the generated code must be thrown away. It should never, under any circumstances, end up in production. You’re not building software, you’re communicating an idea. The prototype exists to be seen, reacted to, and then deleted.
One of our colleagues built a rough prototype for a feature idea, just to show what it could look like. It was a proof of concept, nothing more. But weeks later, engineers referenced that prototype when planning a real initiative around the same topic. A scrappy afternoon demo turned into the starting point for actual engineering work.
That’s what prototypes do that briefs can’t. They generate momentum. People see an interactive demo and say “oh, and we could also do this” and “what if we added that.” The conversation shifts from “should we build this?” to “how should we build this?” And then proper design and engineering take over.
Prototypes also prove ideas are bad
This works in the other direction too, and that might be even more valuable.
If you spend 30 minutes talking to Claude about a feature idea and the result feels wrong when you see it… you’ve saved everyone a lot of time. Delete the branch, the environment disappears, and you move on. No lengthy product brief. No technical discovery. No three weeks of back-and-forth before someone finally admits the idea doesn’t work. Quick invalidation is underrated.
Why this only works with real data
Say you want to test a new category page layout for an e-commerce site. You build something locally with three test categories named “Category 1,” “Category 2,” and “Category 3.” It looks fine. But your production store has 47 categories with real names, real images, and wildly different product counts. The layout that looked clean with three placeholders falls apart.
Local environments have fake data. Staging has stale data. Upsun preview environments clone your production environment, data included. When you create a branch from production, your preview runs under the same conditions with the same data. It’s disposable, but it’s not degraded. You’re testing your idea against reality, not against a sanitized version of it.
For a deeper look at how preview environments work and what makes them different from traditional staging setups, see Preview environments: a developer’s secret weapon.
Git push is the whole workflow
There’s no deploy pipeline to configure. No environment to provision. You push a branch and an environment exists. Every branch gets its own isolated world with its own URL, database, and services. It’s not a shared staging environment where four people are fighting for access. Push again to update it. Delete the branch when you’re done and everything disappears.
You can do this too
None of this is internal tooling. Any team running on Upsun can do the same thing tomorrow. Point an AI coding assistant at your codebase, describe what you want to prototype, push the branch, and share the preview URL. Product managers, designers exploring layout ideas, support engineers reproducing customer issues… anyone who needs to get an idea out of their head and into something people can interact with.
This isn’t an AI strategy memo. It’s a daily habit. The code is messy. The prototypes are rough. But ideas move faster from “I think this could work” to “look at this and tell me what you think,” and that’s the gap that actually needed closing. Last modified on April 14, 2026
