Prototype Feedback: 14-Day Must-Pay Test at 60% — Build or Kill

This guide delivers a pre-committed 14-day prototype test: build only when paid commitments ÷ qualified testers reach 0.60 by day 14.

The build-or-kill rule above is applied mechanically at day 14; the sections that follow explain how to run it, what the evidence does and does not support, and what to do with the result.

How the 14-day paid-deposit test works

The mechanism has three locked parts: a refundable deposit as the payment signal, a 14-day clock, and a qualified-tester denominator. Before the first tester sees the prototype, write the qualification rule and the clock start in the same place, then treat both as immutable through day 14. The decision rule is paid commitments divided by qualified testers, compared against the pre-committed threshold.

Define a qualified tester before day 1 as a person who matches the target segment and completes the prototype walkthrough. A walkthrough from someone outside the segment, or one that stops before completion, is unqualified and never enters the denominator. Use this as a gate, not a cleanup step: if a tester does not meet both conditions, do not count the walkthrough even if the person is enthusiastic or asks to pay.

The payment signal is a refundable deposit collected inside the 14-day window. It is not a survey answer and not a waitlist email. Refundability removes politeness bias because the tester can get the money back, but the act of paying still costs real money and attention; that friction is what separates a deposit from a free expression of interest. Collect the deposit through the same path for every qualified tester so the signal stays comparable.

Day 14 is a hard stop. There are no extensions and no “just five more testers” after the lock. At day 14, compute paid commitments divided by qualified testers using only testers who were qualified under the definition written before day 1. The only permitted change to the denominator is the one written into the pre-test charter for withdrawn deposits — for example, recomputing the ratio if a deposit is refunded before day 14 — and it must be applied exactly as written, not improvised at the tally. If the ratio is at least 0.60, build; otherwise kill the prototype and reallocate the team.

Run the test as a sequence of checks rather than a loose feedback round: confirm segment match, confirm walkthrough completion, record the deposit status, and freeze the denominator. This keeps the final ratio tied to the same population and the same window, so the day-14 number reflects commitment rather than enthusiasm gathered after the fact.

What the evidence actually supports

The evidence base for a paid-deposit gate is thinner than most build-decision frameworks admit, and an honest audit says so before it says anything else. The LinkedIn piece "Test Before Committing: Prototyping for Early Feedback" makes exactly one grounded claim: prototypes are "an option, not a commitment" and "a way to buy information." That is a conceptual frame, not a measurement. The article supplies no participant counts, no conversion rates, and no dollar figures, so none may be cited from it. If you see a writer attach a percentage to that source, the percentage was invented.

The companion piece, "How to Validate Your Business Idea Without a Prototype," is similarly bounded. Its grounded claim is that validation methods vary by "stage, budget, and goals," and that assumptions can be tested without a prototype at all. Again: no numeric threshold, no sample size, no observed conversion rate. The practical takeaway is a check, not a number — before you run any test, write down which assumption it is meant to falsify, and confirm that the method you chose actually touches that assumption rather than a neighboring one.

Two other sources in the set are useful only as negative controls. The Prototype2Fix GitHub repository documents a Steam processor-affinity workaround for a game crash — a real fix, but about software configuration, not customer commitment. The RAYPCB page describes prototype manufacturing as quote-driven: you send board files, quantity, and a required date, and you receive a project-specific quote. That confirms prototype unit cost is quote-driven, which is why this guide never prints a unit price. Neither source can support a conversion threshold.

What remains is the convergence table, and it is deliberately short. Only two sources speak to prototyping as an information purchase, and both speak conceptually. Zero sources in this set report a paid-commitment rate against a qualified-tester denominator. That is the entire evidentiary yield.

Read the table as a build-decision input, not a literature review. The convergence is conceptual: prototypes buy information, and validation design depends on stage, budget, and goals. The divergence is total on numbers — nothing here validates 60%, and nothing here refutes it. So treat 60% as this guide's pre-committed operating threshold, written down before the first tester sees the prototype, and treat the audit above as the reason you cannot borrow someone else's figure to replace it.

Options compared: deposit vs. survey vs. waitlist

Among the three candidate signals, only a refundable deposit earns a build decision; survey intent and waitlist email do not. The deposit wins because it is the only signal that costs the tester real money and forces a real decision, while still being ethical and reversible through refundability. It is also the only option that produces a falsifiable ratio against a locked denominator, so the result can be checked rather than interpreted.

A refundable deposit is not a purchase; it is a costly signal. The tester must move money, which separates interest from politeness, and the refund keeps the test reversible if the prototype is killed. Because the denominator is fixed before testing, the count of paid commitments can be compared against it without post-hoc redefinition.

Survey intent—“would you buy?”—costs the tester nothing, so it measures politeness, not demand. It is useful only as a pre-filter to build the qualified-tester list, not as evidence that anyone will pay. Treat a positive survey as permission to ask for money, not as money itself.

A waitlist email measures curiosity, not willingness to pay. A waitlist signup can be produced by a single tweet, so it cannot stand in for a payment decision. Use it to gauge attention or message fit, then require a deposit before counting the tester as committed.

The LinkedIn piece “Test Before Committing: Prototyping for Early Feedback” frames early prototypes as a way to buy information; a deposit is the price the tester pays to make that information falsifiable.

Costs and numbers that matter

Prototype unit cost is not a catalog line item. Per RAYPCB, bare PCB prototype manufacturing is quoted per project from board files, quantity, and required date, so the only defensible budget line is a project-specific quote requested before the test starts. Do not rely on an assumed list price; request the quote yourself and re-quote if the board revision, quantity, or required date changes.

The 14-day window has its own price: team size multiplied by 14 days of loaded daily cost. That product is the real cost of running the test, and it must be smaller than the cost of building the wrong thing. If it is not, shorten the scope or the team before day one; do not discover the overrun at day 14.

Use the loaded rate your finance function already uses for project costing—salary, benefits, and allocated overhead—not a stripped-down salary figure. A low rate makes the test look cheap and hides the real price.

Set the deposit high enough that a yes is uncomfortable, but low enough that a genuine buyer can still say yes. The amount is a judgment call tied to your price and buyer budget, not a universal figure; document the chosen amount and the reason in the same pre-test note as the threshold.

For the deposit, remember it is refundable, so book it as a liability or escrow-style commitment, not revenue. The cost question is not margin; it is whether the payment behavior is strong enough to justify the build.

Keep these three numbers separate in the decision record: the quote is a vendor fact, the opportunity cost is an internal estimate, and the deposit is a behavioral threshold. Mixing them into one "test cost" figure hides which one actually moved the build-or-kill call.

What the evidence does NOT establish

The 60% paid-deposit threshold is this guide's decision rule, not a sourced benchmark. No grounded source provides a paid-conversion benchmark, so the 60% figure is chosen for falsifiability: it is pre-committed, binary, and easy to audit at day 14. It is not an empirically derived conversion rate, and it should be labeled as method wherever it appears.

The 14-day window is also a method choice. No grounded source specifies a test duration. The LinkedIn piece on prototyping as an option, not a commitment, frames prototypes as a way to buy information and implies a bounded window, but it names no length. Fourteen days is therefore an operational decision, not a sourced standard; if a team changes it, the change should be written before the first tester sees the prototype.

The evidence also does not establish that a deposit predicts later build success. The gate measures whether enough qualified testers will pay a refundable deposit within the chosen window; it does not prove demand, retention, or revenue after launch. Treat the result as a stop-or-go screen, not as validation of the whole product.

Because neither the 60% threshold nor the 14-day window comes from a grounded source, both must be treated as internal method. The only safe claim is procedural: pre-commit the rule, apply it exactly, and record why any exception was made.

25 testers, day-14 tally

Run the arithmetic before you run the meeting. Forty people are invited; twenty-five complete the walkthrough and match the target segment, so qualified testers equal 25. The deposit is set at a refundable amount, and the window is locked at 14 days. Those three numbers — 25, the refundable deposit, 14 days — are the only inputs the day-14 tally needs. Write them at the top of the worksheet before the first tester opens the prototype, because every later percentage is a division you cannot renegotiate once the clock starts.

Checkpoint 1 lands on day 3. Six deposits are collected. Six divided by 25 is 0.24, or 24.0%. That is below the 60% pace, but the window is still open, so no decision is made yet. The check at day 3 is not a verdict; it is a pace reading. Log the number, note the gap, and keep the clock running. Killing a prototype at day 3 because 24.0% looks small would confuse a snapshot with a trend.

Checkpoint 2 lands on day 7. Eleven deposits are collected. Eleven divided by 25 is 0.44, or 44.0%. Still below 60%, and now the gap is worth naming precisely: 60.0% minus 44.0% equals 16.0 percentage points. Flag that 16.0-point gap on the worksheet. It tells you how many more paid commitments the remaining seven days must produce to clear the threshold — and whether that lift is plausible given the pace from day 3 to day 7.

Here is the day-14 tally worksheet, worked with the article's own test setup (25 qualified testers, a refundable deposit, a 14-day window). Enter the deposit count for each checkpoint as the test runs; the decision line is computed at day 14.

At day 14, divide the final deposit count by 25 and compare it to 0.60. If the rate is at or above 60.0%, build. If it is below 60.0%, kill the prototype and reallocate the team. The day-3 and day-7 readings do not change that rule; they only tell you how the test was trending while the window was open. The threshold and the window were pre-committed in writing before the first tester saw the prototype, so the day-14 tally is a reading, not a debate.

Decision rules: build or kill at day 14

The five if/then rules below are the entire decision layer. Nothing else in the test earns a build vote. Write them into the test charter before the first tester sees the prototype, and apply them mechanically at day 14 — no committee meeting, no reinterpretation of the ratio after the fact.

Rule 1 — the denominator gate. If qualified testers at day 14 number fewer than 20, do not apply the 60% rule at all. A ratio built on a handful of testers is too noisy to carry a build-or-kill decision, and a single late deposit can swing it by several points. In that case, either extend recruitment and restart the clock, or kill on qualitative grounds — and record in the decision log which of the two you chose and why. What you must not do is compute the ratio anyway and treat it as evidence.

Rule 2 — the build trigger. If deposits divided by qualified testers is greater than or equal to 0.60 at day 14, build. Commit the build budget within 7 days of the decision so the signal is not wasted; a paid commitment that sits unactioned for a month decays into the same information you would have gotten from a survey.

Rule 3 — the kill trigger. If deposits divided by qualified testers is below 0.60 at day 14, kill the prototype and reallocate the team. Do not run a second 14-day window on the same prototype. A rerun on the same artifact is not a new test; it is the same test with a longer deadline, and it converts a clean kill into a slow one.

Rule 4 — the arithmetic check. Compute the ratio once, from the locked denominator, and verify it before anyone speaks. The table below shows the boundary cases so the team can see where the line falls without arguing about it.

Rule 5 — the tie-break. If the ratio lands exactly on 0.60, build. The threshold is inclusive, and the charter should say so in one sentence so no one spends the day-14 meeting litigating a boundary that was already decided. If the ratio lands below 0.60 but the team believes the prototype is worth one more look, that belief is not a rule — it is a new proposal, and it has to clear the same pre-commitment in writing before any tester sees anything.

Apply all five rules in order: check the denominator first, then the ratio, then the action. The order matters, because Rule 1 exists precisely to stop Rules 2 and 3 from being applied to a number that cannot support them.

What to do next

Frequently Asked Questions

At what paid-deposit ratio does the 14-day prototype test earn a build decision?

A 14-day prototype test earns a build decision only at a 60% paid-deposit threshold.

What is the exact formula used to decide whether to build or kill the prototype?

Build only if paid commitments ÷ qualified testers ≥ 0.60 at day 14; below 60%, kill the prototype and reallocate the team.

When must the threshold and window be locked in before testing begins?

Pre-commit the 60% threshold and the 14-day window in writing before the first tester sees the prototype.

What are the three locked parts of the 14-day paid-deposit test mechanism?

The mechanism has three locked parts: a refundable deposit as the payment signal, a 14-day clock, and a qualified-tester denominator.

Can validation happen without building a prototype at all?

Business ideas can be validated without a prototype using methods matched to stage, budget, and goals.

How should the prototype itself be treated in decision-making terms?

Treat the prototype as an option, not a commitment — it buys information.

Quick answers

Also worth reading: The 15-Minute COO Huddle: Cutting Decision Latency: 15-Minute COO Huddle: Cutting Decision · The 48-Hour Decision Clock: Speed and Quality at 50 Employees: 48-Hour Decision Clock: Speed and · Reorg Decision Latency: The 48-Hour Cadence and Its Limits: Reorg Decision Latency: The 48-Hour