How to ship a POC in an afternoon: a Claude Code and Upsun walkthrough for product and product marketing

I have an Upsun project that's nothing but proofs of concept.

It's a dashboard, basically. Each POC gets its own tile. Click in, and you land on a page with three tabs. The first tab is a written explanation of what the POC argues. The second tab is the POC itself, with a built-in demo that automates a walkthrough of the feature so the recipient can watch it run without me on the call. The third tab is a list of the product primitives that already exist to support this POC, plus the ones we'd actually have to build to make the thing ship for real.

I didn't build the dashboard. I asked Claude to build the dashboard. Then I started living inside it.

When someone on product or engineering wants to see what I've been thinking about, I send the dashboard URL. They pick a tile. The conversation that follows is twice as good as the one I used to have with a slide deck.

This post is the walkthrough I wish someone had handed me before any of that existed. I'm going to assume you're a product manager or a product marketer who has never deployed an app, who has a real product idea you want to make tangible, and who has been told you should learn to vibe code. By the end of this post, you'll have the path, the tools, and the specific skills and MCPs that pull the most weight.

(Side note on terminology. We're calling it AI-augmented development from here on. Same thing, sounds fancier, harder to dismiss in a board meeting.)

A note on stakes before we start. The artifact you build here is a conversation tool, not production code. The line matters. We'll come back to it.

One more assumption I'm making: you don't have a hard token cap on your AI usage at work. If you do, this changes the math a little. Build the foundation in stages instead of one afternoon. Set up your product template, your principles file, and your dashboard across a few sessions. Once that foundation exists, every new POC after it costs a fraction of the tokens, because the AI is mostly cloning and tweaking instead of generating from scratch.

What you actually need

Three things.

1. An AI coding tool. The most accessible option, by a long way, is the Claude Desktop app. Sign in, click over to the Claude Code tab. That's it. The same workflow works in OpenAI's Codex or Google's Antigravity if your team prefers one of those.
2. An Upsun account. This is where your POC lives so other people can click it. Sign up at upsun.com.
3. A clear idea of what the POC needs to argue. This is the part most people skip. We'll talk about it.

You do not need to know JavaScript, Python, Docker, or any of the rest. You need to know what your idea is supposed to do. The AI handles the technical load. You handle the product judgment.

Heads up if your company won't let you use a desktop AI app. If you're required to use your own API key, opencode is the open-source CLI I've used. Slightly more setup. Same end result.

Step 1: Open the tool and pick a folder

If you've never used an AI coding tool, start with Claude Desktop. Download it, sign in, and click over to the Claude Code tab.

Here's the thing nobody tells you up front: you have to pick a folder. Claude Code (and every other agentic coding tool) works inside a single project directory on your computer.

You do not need a separate folder for every POC, and I'd actively recommend against it. The pattern I use is one folder for everything. Your product template lives in it. Every POC lives in it. Your dashboard lives in it. When you want to start your fifth POC, you open Claude Code in the same folder and say "let's start another POC." The AI already has all the context: your template, your principles, your past POCs, your dashboard.

Create a new empty folder somewhere sensible (Desktop, Documents, wherever your work files live). Name it pocs and let it grow. Point Claude Code at it when it asks. From now on, every file the AI writes lives inside it.

Codex, Antigravity, and opencode work the same way. Pick a folder first, then start the conversation.

Don't agonize over which tool to pick. The work matters more than the tool.

Step 2: Set up your skills and MCPs first

Counterintuitively, the right move before your first prompt is to install your skills and MCPs. They change how the AI behaves from the very first message, and one of them (grill-me) is specifically designed to make your first prompt land cleaner.

Skills are reusable instructions the AI follows automatically. MCP servers are connectors to other tools (Notion, Linear, Figma, Slack, GitHub, and so on). Plugins are bundles of both.

The list of what to install is overwhelming if you go shopping. Don't go shopping.

The prompt I actually use is something like:

"I'm using Claude Desktop on Mac. Install the grill-me skill from Matt Pocock's repo, the Upsun skill, and Context7 for me. Walk me through any setup I need to do, or just do it directly if you can."

That's it. The AI knows how its own ecosystem works. Let it do the install. You're not optimizing for an elegant skill list. You're optimizing for the next prototype.

The three I install on every POC project:

• Matt Pocock's skills repo, especially the grill-me skill. It forces the AI to interrogate you about your idea before it generates anything. Catches half my bad assumptions before they become bad code.
• The Upsun skill. Teaches Claude how to write Upsun config files correctly the first time. Saves you a deploy round-trip.
• Context7. Feeds the AI fresh documentation for whatever library you're using. Without it, the AI occasionally makes up function names. With it, the code actually compiles.

Beyond those, install the MCPs for the tools where your context actually lives. Notion or Confluence for spec docs. Linear or Jira for tickets. Figma for designs. Slack for customer conversations.

Step 3: Frame the prompt like a product brief

This is the part most non-engineers get wrong on their first try. They type "build me an app that does X." The result is a generic shell that doesn't quite do X.

Frame it the way you'd brief a senior engineer who you trust to make decisions, and lean on the skills you just installed.

A bad first prompt:

"Build a tool where users can upload a CSV and see a chart."

A better first prompt:

"I'm a product marketer at a developer tools company. I want to build a clickable POC that demonstrates a single positioning idea: 'your team's onboarding doc is the product.' Use grill-me first to push back on my framing and surface anything I haven't thought through. Once we've sharpened the brief, here's the shape I have in mind: two-page web app. Page one accepts a markdown file. Page two renders a clickable, navigable version with a sidebar of headings and a 'rate this section' widget at the bottom of each section. Use React. Use the Upsun skill so the project is deploy-ready for Upsun from the start. No auth, no database, in-memory state is fine. This is a throwaway prototype. Optimize for me being able to demo it Thursday."

The difference: you've told the AI what the POC is for, what shape it should take, which skills to invoke, what you're optimizing for, and what tradeoffs are okay. Same brief you'd give a senior engineer. Same brief works here.

Tip: feed it your real product. At minimum, drag in three or four screenshots of your production app so the POC inherits your real look and feel. Better, give the AI your product's URL and tell it to read your site, figure out the stack you're using, and recreate it as closely as it can. The closer your POC looks to the real thing, the easier it is for engineers and customers to react to the idea instead of getting distracted by unfamiliar UI.

Tip: start in plan mode. Most agentic tools have one. It makes the AI propose a plan before it touches a single file. Read the plan, push back on anything that's off, switch to auto mode once you've agreed on what's getting built. This is a POC. Fast and dirty. But "dirty" still benefits from a five-minute plan.

Step 4: Iterate out loud

Once the AI starts building, your job is to talk to it like a colleague who has all the technical skill and none of your product context.

What works:

• "The button on page two is too small. Make it feel like a primary CTA, not a footer link."
• "When I upload a file with no headings, the sidebar is empty and the page looks broken. Show a helpful empty state."
• "This is too polished. Make it look more like a prototype, on purpose. Less production, more sketch."

What doesn't:

• Vague directives. "Make it better." The AI will make something different. It won't be better.
• Stacked changes in a single message. Hand it one thing at a time. You'll move faster, not slower.
• Treating it like a finished spec. The POC will reveal that you didn't actually know what you wanted. Good. That's the point.

Most of my POCs go through 15-25 rounds of this conversation in the first hour. That's normal. The conversation is the work.

Tip: tell the AI to write down its principles. Something like, "Create a PRINCIPLES.md in this project. Record the design choices we just agreed on, and update it any time we change one." My standing principles look like: API first. Mobile first. Always offer a light and dark mode. Give me two versions to choose from, not one. Always clone the template, never edit it directly. Once those are written down, you stop re-explaining your taste on every new chat. The next session reads the file and picks up where you left off.

Step 5: Deploy to Upsun

Now you have a working app on your laptop. Your engineer can't see it from there. This is where Upsun comes in.

Upsun is a cloud application platform. Translation: you point it at your project, it figures out how to host it, gives you a URL, and stays out of your way. For a POC, you want exactly this. You do not want to think about servers.

The fast path is to let the AI do all the setup work through the Upsun MCP server. You log in once. The AI does the rest.

1. Sign up or log in at upsun.com.
2. Click your name in the upper right corner of the Upsun console to open the profile menu, then click "API Tokens." Generate a token and copy it.
3. Drop this in your AI:

“I want to deploy this project to Upsun. I have an Upsun API token I'll paste in next. Treat the token as a secret: don't repeat it back to me, don't write it to any visible file, don't log it. Install the Upsun MCP server with read/write enabled (the default is read-only, we need write so you can create the project), then create a new Upsun project, push this codebase, and give me the URL when it's done.”

A word on the token. That API token is the keys to your Upsun account. Don't paste it in Slack. Don't commit it to a repo. Don't share it with a coworker who already has their own login. The "treat this as a secret" line in the prompt above is there on purpose, including it tells the AI to keep the token out of logs and files where someone else could read it later.

The AI installs the MCP, talks to Upsun directly, creates the project, pushes the code, and hands you a URL. Usually a few minutes end-to-end.

Tip: CLI as backup. If the MCP gets stuck for any reason, fall back to the Upsun CLI: "Switch to the Upsun CLI. Install it, run upsun login, create a project, and push." Same result, slightly more manual.

The official MCP walkthrough lives at developer.upsun.com.

If something errors anywhere along the way, paste the error back into the AI. Nine times out of ten, it knows the fix.

Step 6: Make it accessible (the dashboard pattern)

This is the move I wish someone had handed me six months ago.

Don't deploy each POC as a standalone app you have to dig through Slack threads to find. Build one Upsun project that hosts all of your POCs, and put a dashboard at the front. Because your folder from Step 1 already contains the template, every POC, and the dashboard side-by-side, the whole thing deploys together as a single Upsun project. The dashboard is just the front door.

Each POC gets a tile. Each tile links to a page with three tabs:

1. The argument. A written explanation of what the POC is and what idea it's making the case for.
2. The demo. The POC itself, with a built-in walkthrough button that automates a tour through the feature. Drop the link in Slack, let the recipient watch it work on their own time.
3. The primitives. A list of what already exists in our real product to support this POC, plus what would have to be built to ship the feature for real.

That third tab is the one that earns the engineering team's trust. It says, plainly, “I'm not pretending this is easy. Here's what we'd actually have to build.”

Tip: build a template of your real product, once. Spend an afternoon creating a stripped-down scaffold that looks and feels like your actual product. Major UI components in place, no real backend, mock data. From then on, every new POC starts with git clone from that template. You're already 30% done. Your demos look like the product. Your engineers stop wincing at unfamiliar UI patterns in your prototypes.

Tip: build your own POC skill after a couple of runs. Once you've shipped one or two POCs and figured out what your personal process looks like, ask the AI to package that workflow into a custom skill. Tell it your conventions (folder structure, README format, primitives-tab pattern, Upsun config style) and have it create the skill for you. After that, every POC starts with the right scaffolding automatically.

Tip: the second POC is much faster than the first. Once your folder has a template, a principles file, a dashboard, and at least one POC in it, your prompt for the next POC collapses to one sentence: "Let's start another POC. Here's the idea: [your idea]. Clone the template, add a tile to the dashboard, follow the principles." The AI does the rest. Most of my POCs after the first one go up in under an hour because all the scaffolding is already there.

Step 7: Share it like a prototype

This is the cultural part. How you share the POC determines whether it stays a POC or accidentally becomes the starting point for production.

I'm not big on "POC alert!" formality. Nobody actually talks like that. What I send in Slack is closer to:

"ok so hear me out....what if [the idea this POC argues for]? Working sketch here: [link]. Click around for a few. Tell me what reads, what doesn't, and what you'd cut. This is a POC, not a starting point. Tossing the code either way."

The casual "hear me out" framing matters. It invites a conversation instead of demanding a review. The "POC, not a starting point" line draws the production-vs-prototype line on purpose, so nobody mistakes the working app for a head start on the production system.

Don't skip the framing.

The recommended starter kit (in one place)

A copy-paste version of what to install.

AI tool:

• Claude Desktop app (most accessible), Claude Code tab
• Alternatives: Codex, Antigravity, or opencode if your company requires API keys

Skills:

• Matt Pocock's skills repo, especially grill-me
• The Upsun skill
• Context7
• Your own custom POC skill (after a couple of POCs)

MCPs (install where your team actually lives):

• Notion or Confluence
• Linear, Jira, or Asana
• Figma
• Slack
• GitHub (optional)

Project hygiene:

• A PRINCIPLES.md file the AI maintains
• A working template of your real product to clone from for new POCs
• One Upsun project that hosts all your POCs, with a dashboard

You can be operational in an hour. Faster if you let the AI do the installing.

The tradeoff I owe you

POCs built this way have a real failure mode. They look done. A working app with real buttons creates the illusion of completeness. When the demo lands, the natural next question is "okay, let's ship it" and that's where teams get into trouble. The code the AI wrote in an afternoon is not the code anyone should run in front of customers. Gartner warned that "prompt-to-app approaches adopted by citizen developers will increase software defects by 2500%" by 2028. They're right about what happens when nobody draws the line.

Draw the line. Then cross it on purpose, with the engineer driving. The POC was the conversation. The product is the next thing you build, with the right people, the right rigor, and the right architecture.

Back to the dashboard

The dashboard wasn't the plan.

My first POC went up as its own standalone project. So did the second. By the third or fourth, I had a mess: links scattered across Slack threads, half of them stale, nobody able to find yesterday's demo when they wanted to show a coworker.

So I asked Claude to build the dashboard. Same workflow as every other POC. Two hours later I had a tiled page that pulled all of them into one place, with the three-tab format I described above. Now I send one URL and let the recipient browse.

This is the thing nobody tells you. The most valuable artifact in this workflow isn't any individual POC. It's the system you build around them, which makes the POCs accessible to everyone else.

Build the ugly thing. Deploy it to Upsun. Make it accessible. Then make the next one easier than the last one.

The prototype isn't the product. It's the fastest argument you can make for what the product could be. The dashboard, eight months in, is the argument that all of this works.

Now go ship one.