Building "Meant to Be Thrown Away" MVPs and Mocks with AI: How to Prototype in the Claude Code Era

Hello, this is Ryuta Hamamoto from TIMEWELL.

The other day, an acquaintance who is thinking about going independent came to me for advice: "I have an app idea, but I can't afford to hire an engineer, so I can't move on it." I opened Claude Code on the spot, spent about ten minutes typing his concept into it in plain Japanese, and out came a prototype that ran in the browser. As he tapped through the screens he started saying, one after another, things he had never been able to put into words: "Oh, this is wrong. It shouldn't go in this order." The barrier to building has dropped, astonishingly so.

That is exactly why I want to tell you something that sounds like a paradox. In an era when anyone can build, the winning move is not "building well" but "throwing things away cheerfully." Because AI has made prototyping instantaneous, many people escape into "building" and get stuck, unable to move, clinging to what they made. This article is a practical playbook for running MVPs and mocks with AI (Claude Code in particular) as your partner, on the assumption from the very start that you will throw them away. It is one entry in a series that walks through building a new business step by step; the map of the whole thing is in the Complete Guide to the New Business Framework. If, before you get your hands dirty, you want to know how much room your company still has to make use of AI, try the AI Literacy Check first; it should make the later sections on how to use AI land much more smoothly.

An MVP or Mock Is Not a "Miniature Version of the Product"

When people hear "MVP" or "Mock," most picture "a shrunk-down version of the real product." This is the first place they stumble. An MVP (Minimum Viable Product) is not a reduced copy of the product. It is a working experiment for confirming a hypothesis. Put another way, it is the working hypothesis itself. The goal is not to write code, and not to make something good; it is to validate a hypothesis as fast as possible, or to put it more honestly, to find where you are wrong as fast as possible.

Why "show a working thing" rather than "explain in words"? Because a working screen instantly raises the resolution of the conversation. Even with the same phrase, "the customer management screen," the picture in each person's head is completely different. A gap in understanding that a hundred written explanations cannot close is suddenly aligned the moment you show a single working screen: "Ah, that's what you mean." In my experience, a conversation held in front of a working thing is many times more concrete than one held in front of a document, because the other person touches the screen with their finger and tells you "this part is wrong."

Let me sort out the vocabulary first, too. A Mock shows a sample of the screens or the experience to gauge reactions, even if nothing works underneath. A PoC (Proof of Concept) proves whether something is technically feasible. A Prototype is close to an umbrella term for all of these. As validation formats, there are also the names we will touch on in detail later: the Smoke Test (lightly "smoking out" whether demand exists), the Concierge (a person delivers the service by hand behind the scenes), and the Wizard of Oz (manual behind the curtain while it looks automatic out front). And the star of today's article is a way of thinking called Throwaway.

Throughout this article, I will use a fictional new business, "Comeback Salon," as the running example. The setup: a tool for owners of small, individually run hair salons (one or two chairs, roughly 8 million yen in annual revenue) that automatically finds regulars whose visits have started to fall off and sends them a "come back" coupon over LINE. Read along while substituting your own business.

Why Build "to Be Thrown Away"

You write MVP code on the assumption that roughly 80% of it will be thrown away. This is the Throwaway mindset. The moment you decide it is meant to be discarded, the shortcuts that would normally trigger guilt all turn into correct decisions. You can build it with no-code tools. Your data can be hard-coded and typed in by hand. The back end can be run manually by a human. You can completely ignore "future scale." Since you are going to throw it away anyway, you need neither extensibility nor clean design. All you need is the single minimal point that lets you confirm the hypothesis.

Conversely, the moment you try to raise the level of finish even a little, the Mock gets promoted from "prototype" to "work of art." Once it becomes a work of art, people can no longer throw it away. The feeling of "I've come this far, so..." dulls your judgment about the business. This is called the sunk cost trap: costs or effort you have already paid and cannot get back. The more heavily you build early on, the harder it becomes to decide to withdraw or change direction. The lighter you build, the more nimbly you can throw it away and move on once you learn you were wrong. Ease of throwing away translates directly into speed of learning.

Here lies a pitfall unique to the age of AI. Because building has become easy, people can now escape into "building" endlessly. Talking to customers is scary, tedious, and being rejected hurts. Compared with that, holing up in your room polishing a mock alongside AI is far more comfortable. That is exactly why I believe the real crux of Vibe Coding (building code by feel while chatting with AI) is not "the courage to build" but "the courage to throw away." In an age when anyone can build, what defines the shape of a business is whether you can throw things away instead of running from that.

Choose Among the Four Types of MVP "in Order of Cheap and Fast"

Starting to build a working product right away is usually the long way around. Match the means to what you want to validate and pick the one that lets you confirm it most cheaply and quickly. The four representative types are below; remember that the ones near the top are cheaper and faster.

Type of MVP	What you do	Good for confirming
Smoke Test	Put up only a landing page and ads	How much demand there is
Concierge	Deliver the whole service by hand	Whether the value truly resonates
Wizard of Oz	Manual behind the scenes, automatic out front	Whether the experience or UI holds up
Mechanical	Implement an actually working product	Whether it functions as a working thing

The Smoke Test measures the volume of demand before you have built anything. You prepare a single page introducing the service, run a small amount of ad spend, and watch how many times the "Sign up" button gets pressed. The famous examples are the Dropbox and Zappos stories, where the teams are said to have gathered reactions with an intro video or a page before the product was finished, confirmed demand, and only then moved into full-scale development. Concierge is delivering the service by hand yourself, without building any system. Wizard of Oz refers to a state where, from the user's point of view, it looks like it runs automatically, but behind the scenes a person is busily doing the work by hand. And Mechanical is the implementation of a so-called working product.

What you must not do is jump straight to Mechanical when the thing you want to confirm is "whether the value resonates." Realizing "I built it but no one uses it" after a full implementation is the most expensive kind of failure. For Comeback Salon, the biggest source of anxiety was "whether owners will want it enough to pay for it." So we choose Concierge first. You personally take custody of the customer lists of a few owner acquaintances, sift out the regulars who are on the verge of drifting away, even write the LINE message that should be sent, and hand it over. Whether doing it by hand delights them tells you whether the value exists. In parallel, you prepare only the dashboard Mock explained next, for use as the Wizard of Oz that makes it look automatic. That is how it is assembled.

If you are torn over which MVP to choose, the fastest route is to make AI your sparring partner. The following prompt, when you hand it your business hypothesis, will judge "the one thing to build now" with reasons attached.

You are a new-business mentor deeply versed in the Lean Startup and Y Combinator methodologies. For my business hypothesis, judge which of the four types of MVP — Smoke Test (measure the volume of demand with a landing page and ads) / Concierge (deliver the service by hand) / Wizard of Oz (manual behind the scenes, automatic out front) / Mechanical (implement a working product) — is "the one thing to build now," with your reasons. Do not rush into heavy building; always prioritize the cheapest, fastest way to validate.

[My information]
- The main hypothesis I want to validate (just one): who, in what situation, will pay how much for what
- What I'm most anxious about right now: whether there's demand / whether the value resonates / whether the experience holds up / whether it works
- Time available: hours per week / Budget: yen / Can or cannot write code

[What I want you to output]
1. The recommended type of MVP and why you chose it
2. Conversely, "what you don't need to build right now"
3. Three concrete first actions to take this week

When demand itself is hard to read, it helps to get a rough grip on how large the market is beforehand so the decision is easier. How to estimate market size is laid out in How to Calculate Market Size with TAM, SAM, and SOM.

Build a Working Mock the Same Day with Claude Code

Once you have a feel for "whether the value resonates," the next thing you will want is a working Mock to use in Wizard of Oz and beyond. The one tool I recommend here is Claude Code. It is an AI tool that, when you type "build me something like this" in plain language, writes the code and turns it into a working thing; as of 2026 you can start from an individual plan of a few thousand yen a month. Having a working Mock in hand the same day, with no programming experience, is something that was unthinkable a few years ago.

The trick to instructing it is to write just four things in your everyday words. Who it is for. What it is for (which of the customer's jobs it gets done). Which screens are needed (keep it to three or fewer). What the visual tone should be (color, mobile-first, and so on). On top of those four, add a few technical conditions: make it a single file that runs the moment you open it in a browser, make it run on dummy data with no login, show a small "v0.1 (prototype)" in the corner of the screen, and make "just works" the top priority over elaborate design. That one line, "v0.1," is quietly effective, because it keeps people from mistaking it for a finished product.

If assembling the instruction text yourself is hard, you can have AI build that too. Hand the following prompt your information, and it returns an instruction you can paste straight into Claude Code.

You are an assistant that assembles the "Mock creation instructions" to hand to Claude Code (an AI that writes code when you instruct it in plain language). From the information I give you, produce a single instruction, in plain language, that I can copy and paste straight into Claude Code.

[Four things the instruction must include]
1. Who it is for
2. What its purpose is (which of the customer's jobs it gets done)
3. The screens needed (three or fewer)
4. The dummy data to use and the visual tone (color, mobile-first, and so on)

[Technical conditions to put in the instruction]
- A single HTML/CSS/JavaScript file (index.html) that runs the moment you open it in a browser
- Runs with dummy data, no login
- Shows a small "v0.1 (prototype)" in the corner of the screen
- No elaborate design needed. Make "just works" the top priority

[My information]
- Who it's for: (   ) / Purpose: (   ) / Screens: (   ) / Data and tone: (   )

Run this prompt for Comeback Salon and it returns an instruction like the following. This can be pasted straight into Claude Code and used.

Build a Mock of a web app for owners of individually run hair salons that finds regulars on the verge of drifting away and sends them a "come back" coupon. There are three screens. (1) A customer-list dashboard (showing name, last visit date, average visit cycle, and drift risk color-coded red/yellow/green); (2) a coupon-creation screen (choose the discount rate and the expiry date); (3) a send-confirmation screen. Include 20 dummy customer records, and make it run in the browser with no login. Put it all in a single HTML/CSS/JavaScript file, with mobile display prioritized. Show a small "v0.1 (prototype)" in the corner of the screen. The design doesn't need to be elaborate, so prioritize making it work first.

If you build it and the direction is off, no need to hold back. Type "throw it all away and rebuild it," and it will build it again from scratch. Being able to throw it away in an instant is another big advantage of building with AI.

There is also a path where you do not build it with your own hands. Assemble it with no-code tools; ask a family member who is good with everyday IT; consult the (often free) IT advisers at your local chamber of commerce or small-business support center; place a small order on a crowdsourcing platform. Each of these is a perfectly respectable choice. I often hear from people at large companies that "I can't use tools like this on my company PC," but there is no need to give up there. There are legal routes that use your personal PC, your personal time, and your personal email address. That said, be sure to check your employment rules, put in none of your company's confidential information whatsoever, and test only with entirely fictional data. Hold that line.

The "Meant to Be Thrown Away" Script for Showing Customers

This is the part of the article I most want to convey. Eighty percent of MVP-validation failures happen not because of how the Mock turned out, but because of "how you show it." Even when you make a good prototype, if you show it the wrong way, what comes back is not honest opinion but social pleasantry.

When people are handed something that looks like a finished product, they try to praise it. "Nice." "Looks handy." Those words are usually the other person's kindness, not the facts. And, troublingly, the person who built it gets drunk on the praise. Still drunk, they charge off in the wrong direction with everything they have. This is the most common way I see people fall in a new business.

So, before you show it, you declare "this is meant to be thrown away." There are three devices. First, say it with a concrete number: "this is an experimental prototype, and I'll throw away more than half of it next week." Second, cut it off at the pass: "praise actually makes me go in the wrong direction, so it's a bit of a bind for me. Please tell me straight, 'I don't need this.'" Third, put a limit on time: "I only need ten minutes today." Just reading out this preface flips the other person's mode from polite praise to honesty. You can have AI write this script too, tailored to how you speak.

You are an expert in designing customer interviews. Write a "meant to be thrown away" opening script for me to read aloud before showing a customer the Mock (prototype) I built, tailored to my way of speaking. The goal is to tell the customer "this is not a finished product; it's an experiment to gather blunt criticism" so I draw out honest opinion rather than polite praise.

[Devices the script must include]
1. Say it with concrete numbers: "an experimental prototype," "I'll throw away more than half of it next week"
2. Cut it off at the pass: "praise is a bit of a bind (because it sends me the wrong way)"
3. Put a limit on time, such as "just ten minutes"
4. End by asking for one blunt piece of pushback

[My information]
- Who I'm showing it to: (   )
- A one-line description of the Mock I'm showing: (   )
- How I usually speak: gentle / businesslike, and so on

Please output it in spoken language I can read aloud as is. Also tell me the three-line notes I should jot down after the meeting.

For Comeback Salon, you show it to three owner acquaintances after prefacing: "This is still an experimental prototype, and I'll throw away more than half of it next week. Praise actually puts me in a bind, so please tell me straight if you don't need it. I only need ten minutes." The aim is to deliberately collect the painful voices and the one-line rebuttals, not the praise. Start with a rough target of five to twenty customers.

The Three Traps People Who Can Code Fall Into Most

Ironically, the people who can code stumble most on MVPs. Precisely because they can build, they overbuild. There are three traps.

The first is the overbuilding disease. Trying to finish a Mock into a polished product, you fuss over CSS and animations, and before you know it three weeks have gone by. The countermeasure is simple: decide in advance that once you have spent more than seven days, you release it as is, no questions asked, and move to the next cycle. You compete not on the height of quality but on the number of cycles. The second is the feature-adding disease. As you listen to every customer request and pile them on, the Mock bloats. There is an important perspective here. A customer's words "I want this feature" are usually pain expressed in the shape of a "feature." So rather than implementing the request as is, you dig into "why do you want that?" about three times, translate it into the root pain, and only then decide whether to build it. For the knack of translating requests into pain, An Empathy Map for Finding the Customer's Problem and How to Write a Value Proposition Canvas will help too.

The third, and the most dangerous, is the customer-avoidance disease. You spend months building the Mock and, during that whole time, never once meet a customer. While you are building it feels like you are moving forward, but in reality you have validated nothing. The countermeasure is to inspect this one line every week: is "time spent building the Mock ≤ time spent talking with customers" holding true? If build time exceeds talk time, that is a yellow light. Even in Comeback Salon's weekly review, there was a week of 8 hours building the Mock against 3 hours in conversation with customers. That is the textbook state of building too much and talking too little.

Fold the Scope onto One Page and Run It Weekly

The tool for structurally preventing overbuilding is scope management. My recommendation is a prioritization method called MoSCoW, which sorts requirements into four buckets: Must, Should, Could, and Won't (not this time). There is one rule to observe here: keep Must to five items or fewer. The only things allowed into Must are those "without which the validation of the hypothesis itself does not hold." Once Must hits six or more, that is a sign of overbuilding, so cut it in half. And keep the spec to one page. A spec that does not fit on one page is usually too greedy. Fix the deadline at two to four weeks, and when it does not finish, you cut the "scope," not the "product." Once you start repeating "just one more week," that too is a red light.

You can quickly have AI produce a first draft of this one-page spec as well. The key is to have it put in, from the start and as numbers, the disqualifying conditions, the criteria for a Pivot (change of direction), and the criteria for a Kill (withdrawal).

You are an expert in MVP design. Write me a "one-page MVP spec" for my business. Do not inflate it; cut it down to a range that will definitely finish in two to four weeks.

[Premises]
- The main hypothesis to validate (one): (   )
- The disqualifying condition that would mean the hypothesis "failed": (   )
- The assumed customers, and the number I can actually talk to: (   )

[Output format]
1. The hypothesis to validate (one) and its disqualifying condition
2. The type of MVP (one of the four)
3. A primary metric plus two supporting metrics (with numeric targets)
4. Sort the scope with MoSCoW: Must (five items or fewer) / Should / Could / Won't
5. Explicitly state what you deliberately won't do (Out of Scope)
6. Deadlines (start date / date shown to customers / decision date)
7. Criteria for continue / pivot / withdraw (all as numbers)
Finally, self-check "whether Must is too large," and if it is six items or more, propose cuts.

Once you have built it and shown it, all that remains is to run the Build-Measure-Learn loop weekly. Line up what you built this week, the numbers you measured, and the raw voices of customers, and decide whether to continue, change direction, or withdraw. This decision is exactly where AI sparring pays off. Have it push back without reservation on a failed hypothesis you cannot let go of yourself.

You are a coach who runs weekly Lean Startup reviews. I'll hand you the results of the Mock validation I did this week; reflect on it from the Build-Measure-Learn angle and propose one of continue / pivot / withdraw, with reasons. If I'm clinging to a failed hypothesis, call it out without holding back.

[Information I'll give you]
- This week's hypothesis and its disqualifying condition: (   )
- What I built/changed, and the time I spent: (   )
- The numbers I measured: target vs. actual / number of customers I met: (   )
- The raw voices of customers (both good voices and painful ones): (   )
- Time spent building the Mock vs. time spent talking with customers: (   )

[What I want you to output]
1. What went as expected / what was unexpected
2. A check of whether "time spent building the Mock ≤ time spent talking with customers" holds (warn me if it's exceeded)
3. The continue / pivot / withdraw decision and the reasons
4. If pivoting, which to change: customer, value, price, or channel
5. Next week's hypothesis, and what to build and what to measure

Let me run Comeback Salon's second week through this review. "Would like to try it" was 4 of 6 owners. But "would pay 3,000 yen a month" was 1 of 6. The most common raw voice was "being able to see at a glance which customers are about to drift is good. But for now a broadcast blast is enough." On top of that, 8 hours of Mock building against 3 hours of customer conversation shows a touch of the customer-avoidance disease too. The decision here is to pivot. Before dropping the price, either shift the axis of value toward "a personal message for drifting customers only," which a broadcast blast cannot deliver, or change the customer to "newly opened salons that can't fill their bookings and also want to raise their prices." Next week, cut the time spent on the Mock and add at least three more customer conversations. Having decided that, throw the Mock away for now and roll it into the next cycle.

When you have grown attached and can't throw it away, having a throwing-away ritual ready makes it easier to let go. Put the date in the file name; separate things into "adopt" and "throw away" folders. Small devices, but surprisingly effective.

Summary

Now that AI and Claude Code have made prototyping instantaneous, the winning move in building MVPs and mocks has shifted from building well to throwing away cheerfully. Finally, here are the points for taking action starting today.

• An MVP or Mock is not a miniature version of the product but a working hypothesis. The goal is to find where you are wrong as fast as possible
• Build the code on the assumption that 80% gets thrown away. The moment you polish it, it becomes a "work of art" you can no longer discard
• Choose among the four types of MVP in order of cheap-and-fast to validate. Don't jump straight to Mechanical
• Hand Claude Code four things in plain language (who it's for, what it's for, three screens or fewer, tone) and you can have a working Mock the same day
• Read the "meant to be thrown away" script before you show it. Eighty percent of failures come not from how it turned out but from how you showed it
• With MoSCoW, keep Must to five items or fewer, the spec to one page, and the deadline to two to four weeks. Run build-measure-learn weekly

If there is one thing I most want to convey, it is only this: precisely because this is an age when you can build, whether you can throw things away instead of running defines the shape of a business. In a time when anyone can escape into "building," the person who dares to stand in front of customers and go collect their honest criticism is, in the end, the one who gets to the right answer fastest. The courage to throw away is not a talent; it is a habit. Start by putting the date on this week's Mock and throwing it away cleanly next week.

If you want your team to develop the feel for using AI as a partner in building a business, or if you want a companion for launching a new business itself, at our AI consulting service WARP we design validation cycles like these together. When you want to talk through what to tackle first for your own situation, reach out via a WARP individual consultation.

References

• Ryuta Hamamoto, "How to Build a Business in the AI Era, Walking Alongside Your Customers" (TIMEWELL Inc.)
• Eric Ries, "The Lean Startup" (2011)
• Steve Blank, "The Four Steps to the Epiphany" (2005)