How to Build a Working Prototype in 60 Minutes (Step-by-Step)

The short version

The exact 60-minute workflow: 5 minutes framing the problem (write problem statement, list steps, identify constraints, decide scope), 10 minutes describing to Claude Code and getting the first working version deployed to Vercel, 15 minutes iterating UX with specific prompts ("the data mapping step is confusing, add inline help text"), 15 minutes adding real data and edge cases, 15 minutes deploying and sharing. The exact prompts to paste are in the post. You're not building a product in 60 minutes. You're learning what product to build. A prototype with rough edges that teaches you something is infinitely more valuable than a beautiful mockup that's never tested. Pick one feature idea this afternoon and run the workflow.

The old way to prototype: "I need a designer to make some mockups, then a developer to code it, then we'll test it." Three weeks, multiple people, feedback loops that slow you down.

The new way: "I'll describe the problem, show the AI what I mean, iterate for an hour, and have something testable today." You and Claude Code. That's it.

I've used this workflow to prototype everything from SaaS onboarding flows to internal tools to complex data dashboards. It works best when you have a clear problem and you're willing to iterate fast instead of trying to build the "perfect" thing on the first try.

Here's the exact flow, minute by minute, using a concrete example: an enterprise onboarding wizard that guides new SaaS customers through setup, integration, and first use.

Minute 0-5: Frame the Problem

Your job: Get crystal clear on what problem you're solving.

You're not starting with "build me a UI." You're starting with context.

What to do:

1. Write a 2-3 sentence problem statement

   • Who: The user type (new SaaS customer, finance manager, API integrator, etc.)
   • What: The job they're doing (setting up for the first time, integrating their data, learning how to use a feature)
   • Why it matters: What's the cost of them not doing this well? (They give up and churn, it takes IT 6 weeks to set up, they miss key data)

2. List the steps the user needs to complete (not screens, steps)

   • Example: Connect company data, map data fields, choose reporting dashboard, invite team members, send first report

3. Identify any constraints

   • Do they need to connect to external tools? (Salesforce, Google Sheets, etc.)
   • Are there security/compliance requirements?
   • Is this for internal or external users?
   • Does it need to be mobile-responsive?

4. Decide on scope: What will we NOT build?

   • Example: "We're not building real Salesforce integration, we'll use a mock API"
   • "We're not building a full admin panel, just customer-facing setup"
   • "We're focusing on the happy path, not error handling"

Example for our onboarding wizard:

Problem: New SaaS customers are getting stuck during the setup process (currently
manual, requires a support call). They're spending 4-6 hours on a process that should
take 20 minutes. We lose 15% of them to churn in the first month.

User: Finance director at a mid-market company setting up our analytics product for
the first time. They've got 30 minutes, and they want to see their data in a dashboard
in one sitting.

Steps to complete:
1. Authentication (log in or sign up)
2. Connect data source (paste API key, or sync with Salesforce)
3. Field mapping (match their data to our data model)
4. Choose dashboard template
5. Invite team members
6. Send first automated report

Constraints:
- Must work on desktop and mobile
- No real API integration (we'll mock the Salesforce/API calls)
- Must feel like a real product (not a prototype)

Out of scope:
- Error handling beyond "let them retry"
- Complex permission management
- Admin-level configuration

Time check: 5 minutes. You're clear on what you're building.

Minute 5-15: Describe to AI and Get First Version

Your job: Hand off the vision to Claude Code and get a working prototype.

Open Claude Code (or Claude in your browser) and start with this structure:

What to say to Claude Code:

I'm building a new product feature and want to prototype it in 60 minutes. Here's
what I'm solving:

[Paste your problem statement from above]

The user journey is:
1. [Step 1]
2. [Step 2]
... etc

Here's what I want:
- A working web app that walks through this flow
- Each step should be a clear screen/section
- It should feel like a real product (not obviously a prototype, no "PLACEHOLDER" text)
- Modern, clean design (nothing fancy, just professional)
- I'll test it with real users in a few days

Build a single-page app (React/Vue/HTML+JavaScript) that:
1. Shows step 1, collects the necessary input
2. On submit, moves to step 2, etc.
3. At the end, show a "success" screen with a summary of what they did

Make it so I can click through it and it feels smooth. No real backend or API calls yet
(mock the API calls with fake data).

Use [your tech stack: React/Vue/HTML+JS]. Deploy it to [Vercel/Netlify] so I can share
a link.

Start with the basic structure. We'll iterate on specifics in the next 10 minutes.

What Claude Code will do:

• Build a functional prototype in ~2 minutes
• Deploy it to a shareable URL
• Give you a link you can click through

What you do:

• Click through the prototype immediately. Don't wait for it to be perfect. See what it feels like.
• Take 5 minutes to jot down your first reactions:
  • What feels right?
  • What's confusing?
  • What looks weird or wrong?
  • Is the flow obvious or do you have to think about what to do next?
  • Does it match what you imagined?

Time check: 15 minutes. You have something clickable.

Minute 15-30: Iterate on UX

Your job: Make the prototype feel less like a prototype.

Now you refine. You're not starting over, you're fixing specific things.

Run these prompts in sequence:

Prompt 1: "This feels a bit rough. Let me describe what I'd change..."

I just clicked through the prototype. Here's what I want to adjust:

1. [Specific change: "The data mapping step is confusing. Users don't know what
   'source field' vs 'destination field' means. Can you add inline help text?"]

2. [Specific change: "The success screen feels anticlimactic. Instead of just
   saying 'you did it', show them a preview of their data + next steps"]

3. [Specific change: "The colors feel too bold. Use a more muted color palette"]
4. [Specific change: "Step 3 feels like too much at once. Can we split it into
   two screens?"]

Make these changes and redeploy. Keep everything else the same.

Prompt 2: "Now let's make it feel more real..."

Now I want to make this feel less like a mockup. Add:

1. Loading states (when they submit a form, show a spinner for 2 seconds before
   moving to the next step)

2. Micro-interactions (when they click 'next', fade out the current step and
   fade in the next one, don't just swap)

3. Progress indicator (show which step they're on, like "Step 2 of 5")
4. Better form validation (show error messages if they try to submit without
   filling required fields)

Keep the flow the same, just make it feel polished. Redeploy.

Prompt 3: "Let's test a specific user story..."

I want to walk through this specific user scenario and see if it works:

[Describe a specific, realistic user scenario]

For example: "I'm a new customer who's never logged in before. I land on this
page, I need to create an account, then connect my Salesforce data."

Can you make sure the happy path for this scenario is smooth? If something feels
clunky, fix it.

Also: when they land on the first screen, what's the first thing they should
read/click? Make that crystal clear (maybe bold text or a highlight color).

Redeploy.

Prompt 4: "Let me see it on mobile..."

I need to test this on mobile. Make sure:

1. Text is readable (font sizes, no tiny buttons)
2. Form fields are easy to fill on a small screen
3. The layout stacks vertically (not trying to fit everything in columns)
4. CTAs are big enough to tap without missing

Test it on a phone-sized viewport. Redeploy.

What you're doing in these 15 minutes:

• Identifying what feels clunky
• Adding just enough polish that it feels like a real product
• Testing the key user scenarios
• Validating the flow works

Don't get lost in perfectionism here. You're going for "good enough to test with users," not "launch ready."

Time check: 30 minutes. You have a prototype that feels like a real product.

Minute 30-45: Add Real Data and Edge Cases

Your job: Make the prototype feel like it actually works with their data.

Right now it's working with dummy data. This is the step where you either:

• Hook up a real API (if you can do it in 5 minutes)
• Or create realistic mock data that matches their actual data structure

Prompt: "Let's use real data..."

I want to make this feel like it's actually working with our product.

Right now, the data mapping step shows fake fields. Here's what our actual data
looks like:

[Paste the schema of your actual data, or the fields they'll actually see]

Update the mock data in the prototype to match our real data. When they fill out
the data mapping step, show fields that actually exist in our system.

Also, add 2-3 edge cases:

1. [Edge case: "What if the user connects a data source with 500 fields? How do
   we make it searchable?"]

2. [Edge case: "What if they try to map a field that's already been mapped? Show
   an error."]

3. [Edge case: "What if they have data in a format we don't expect? Show a
   helpful error message."]

Redeploy.

Prompt: "Let's add one feature that makes it feel real..."

There's one thing that would make this feel way more real:

[Describe a feature: "Instead of just saying 'report is ready', actually show
them what their first report will look like. Generate a fake report preview based
on the data they set up."]

This doesn't need to be perfect, but it should feel like the feature actually
works.

Redeploy.

What you're doing:

• Validating that the flow works with real-ish data
• Stress-testing edge cases
• Adding one "wow" moment that makes users feel like they're actually using the product

Time check: 45 minutes. You have something that looks and feels like a real product.

Minute 45-60: Deploy and Share

Your job: Get it in front of users.

The last prompt: "Let's make sure this is shareable..."

I'm going to share this with [customers / internal stakeholders / executive team]
in the next few hours. Make sure:

1. The app loads quickly and doesn't have any obvious bugs
2. There are no console errors (test in Chrome DevTools)
3. The mobile version works
4. If someone forgets to fill out a field, they get a clear error
5. The success screen explains what they just did

Do a final test run through the whole flow. If you find anything broken, fix it.

Also: give me the shareable link and any notes on what this is (e.g., "This is a
prototype of the new onboarding flow. Click through to see how new customers will
set up their data.")

Redeploy.

How to share it:

Send the link to whoever needs to see it with a message like this:

I've prototyped our new onboarding flow. Click the link and walk through it as
a new customer:

[Link]

Takes 3 minutes. Let me know:
1. Does the flow make sense?
2. What's confusing?
3. Would you actually use this, or does something feel broken?
4. What would make this better?

We're iterating on this for the next week, so feedback now saves us from building
the wrong thing.

Time check: 60 minutes. You're done.

What You Just Did in 1 Hour

• Built a functional prototype
• Iterated on UX 3-4 times based on your judgment
• Added polish so it feels like a real product
• Tested edge cases
• Got it shareable

This is 10x faster than the traditional "design, build, review, redesign, rebuild" cycle.

Why This Works

1. You're not waiting for someone else. No design sprints, no meetings to align on mockups. You're making it yourself.

2. You're iterating fast. "I don't like this" → 5-minute fix → re-deployed → test again. Compare that to "Let me add that to the backlog and we'll review in the design meeting next week."

3. You're learning what actually works. Mockups lie. Prototypes tell the truth. When you click through it, you immediately know if the flow works or if it's confusing.

4. You can test with real users today. You're not asking "would this work?" You're asking "does this work?" with a real product in their hands.

What NOT to Do

Don't try to build the backend in 60 minutes. Mock all APIs. Fake the data. You're testing flow and UX, not engineering.

Don't get lost in design details. A muted gray and a bold blue matter less than whether the flow makes sense. Ship the prototype with placeholder colors if you have to.

Don't prototype for more than 2 weeks. If you're still iterating on the prototype after 2 weeks, it's time to build the real thing or kill the idea. Prototypes are learning tools, not products.

Don't skip the user feedback step. The prototype is only valuable if you test it with users. One hour building, one hour testing. That's the loop.

After the Prototype

Once you have feedback (from users or stakeholders), you have three options:

Option 1: Kill it. The feedback suggests this isn't the right solution. That's a $0 failure (60 minutes of your time), not a $100k engineering effort that goes nowhere.

Option 2: Iterate the prototype once more. You got 80% of the way there. One more round of changes and it's ready to spec for engineering.

Option 3: Hand to engineering with confidence. You know what you're building. You know it works. You know the user flow. You're not asking eng to guess.

Most of the time, it's option 2 or 3. You saved weeks of back-and-forth by just building the thing instead of talking about it.

The Mindset Shift

This approach only works if you let go of "it needs to be perfect." A prototype with rough edges that teaches you something is infinitely more valuable than a beautiful mockup that's never tested.

You're not building a product in 60 minutes. You're learning what product to build. That's the difference.

Download the companion artifact: the exact prompts to paste into Claude Code, plus a checklist for your 60-minute sprint and a template for sharing feedback with your team.

Sources: Claude Code, Vercel, Netlify.