Prototype Sprint vs MVP: When a Demo Must Be Deleted

A clickable demo can survive with one hardcoded account, three perfect photos, and a button that works only if you tap it in the expected order, but an App Store product cannot.

Money blurs it, and a prototype becomes an MVP because the word makes the invoice easier to approve, until six weeks later somebody asks why the investor demo cannot handle a denied permission, second child, slow network, or newer phone.

The line is not the number of screens, framework, or backend; it is whether the software is allowed to lie.

A prototype is allowed to lie, so it can assume valid data, show a made-up map pin, never take payment, and serve one person on one device, which is a deliberate way to buy an answer cheaply.

An MVP cannot: once somebody trusts it with photos, family records, or payment, it must preserve facts, tell the truth when it cannot act, and provide a way out when the obvious path fails, so the two should be separate engagements.

A prototype has permission to fake the expensive parts

For a private travel journal, a prototype can use a static map, prewritten locations, sample entries, and local photos to test choosing a city, adding a memory, attaching an image, and revisiting the map, because if people do not understand that, account recovery and a map-search boundary can wait.

It beats slides: a prospective customer can point to the expected field; an investor sees the product shape; the team learns whether the hero flow takes six taps before it becomes useful.

Before the sprint, write down:

• Which data is invented or reset on every run.
• Which actions merely animate instead of saving.
• Which user decisions are assumed away.
• Which devices, browsers, and permission outcomes are outside the demo.
• What decision the prototype must make possible.

"Get feedback" is not a decision, but "Find out whether a parent understands an illness episode as the container for a sequence of symptoms and medicines" is, as is "See whether people will pay to turn a photo subject into an editable layer," so end the sprint when the team can decide, not when screens look complete.

Budget it as a disposable experiment, because a presentation in five days demands different choices from taking payment next month, and treating them as the same job turns a small spend into a rescue job.

The first real user turns a demo into a product

In MyKiddos, the app must distinguish children, retain an illness episode, and show a tired, stressed family what they entered, but it does not calculate doses or diagnose: a parent enters the dose and interval, and the app records them with a time-based reminder.

A prototype can show that with a timer and samples, but the product needs a model that survives a second child, corrected temperature, reopened old episode, and photo not held inline in a database row, with indexes for frequent log views, fact-based reports, and widget privacy because a health status on a lock screen is not merely another label.

It uses separate private and shared CloudKit-backed stores, which must be tested for sharing with two devices and two Apple IDs, because a demo share sheet is not sharing.

When the idea is unclear, do not call a demo a product; cut to a smaller promise of one child, temperature and medicine entries, a doctor report, and no family sharing at launch, because a smaller truth is better than a broader lie.

Authentication follows the same rule: a prototype can skip accounts, while an MVP can start with magic links and one role, but if somebody can see another person's photos or health history by guessing an address, the scope is incomplete, not minimal.

Error states are part of the thing you are selling

ClearCut, a native iPhone photo editor, can demonstrate this quickly by letting someone choose a photo, tap a subject, move it over a new background, and export it, but the app must handle large images, refused permissions, failed analysis and export, and the same visual result in preview and final file.

I cap inputs at a 3,072-pixel longest edge for analysis and previews at 1,600, while export uses the full prepared canvas; those limits avoid a memory problem while preserving useful export, whereas a prototype can use carefully sized photos and the product cannot assume every person supplies mine.

PNG preserves alpha, JPEG needs an explicit compression choice, HEIC has a different encoding path, and a PDF goes to Files or sharing rather than Photo Library, so the MVP must say what happened, where the file went, and what to do without permission.

A product needs named controls, usable focus order, legible states, and no meaning encoded only in colour, so on a one-screen sound meter, the changing number must be understandable without watching the animated bar.

Do not build every state before testing; identify failures that decide whether the promise is true, because a map product that cannot explain denied location, a paid photo editor that cannot restore a purchase, and a child-record app that loses a correction have not solved their core flows.

Real data changes the design before it changes the bill

The travel journal prototype was a static HTML reference in prototype/, covering onboarding, map, add-memory, detail, and reflection screens without a build step, which was right for agreeing on the interface but not a production client.

The product moved to Rails, where a trip collection owns visits, a place has a stable identity in that collection, and a pin belongs to a place and visit with photo attachments and a reflection; creating a memory finds or creates the place and persists place and pin in one transaction.

That matters when somebody adds the same café through two search results, loses connection before saving a note, or tries to view an uploaded photo from another account: Rails routes place search through the server, caches it for 12 hours, applies a 25 km city filter, and checks country matches; it stores media privately, confirms download ownership through the record chain, rejects unauthenticated requests, and returns not found to another account.

Ask what happens when the tenth record differs from the first three samples, because if it changes identifiers, ownership, order, upload path, or permissions, do not build a large feature set yet.

Do not optimise for millions of records, but do not store every image in the same row as text or make a screen work only with three seeded records. Use ordinary constraints and pagination where the shape calls for them, not a distributed system to look serious.

A prototype should be deleted when its assumptions are structural

I delete a prototype when extending it would preserve the wrong answer: a prototype/ directory for screens is useful reference material, but wiring production around it because pages look done is the mistake. The travel journal prototype had no persisted routes, authorisation, upload handling, map-provider integration, or relational model, and adding them piecemeal would hide the decisions that mattered, so starting again in Rails was cheaper than making HTML reference material the base of a private multi-client product.

Deletion triggers include:

• Hardcoded identities where the product needs ownership or roles.
• Browser state where the product needs a recoverable record.
• One object where the user has many: one child, one visit, or one editable photo layer.
• Local sample media where the product needs uploads, formats, permissions, and retention rules.
• A direct third-party call where keys, rate limits, caching, or access controls belong on the server.
• A demo that can only be tested by replaying the exact script.

None alone forces a rewrite, so ask whether the missing part is additive: a preferences page is, but replacing a single dictionary with a model with ownership, constraints, migrations, and history is a new foundation, and patching it usually costs more to understand than to replace.

I would rather say the prototype has done its job than sell three weeks of patching, because its value is the decision it produced.

Shipping the prototype usually creates a permanent exception list

The expensive mistake is not deleting a demo but getting customers on it, because every shortcut becomes a support rule: missing permissions mean "ask me before changing that record"; missing export means "email us and we will retrieve it"; no purchase restoration means an angry ticket after a phone change; a fake empty state makes users think data vanished.

NoiseCheck is a one-screen iPhone meter, not a social product with a server fleet, and it requests the microphone when measurement starts before processing each 2,048-frame audio buffer locally; it makes an A-weighted dB(A) estimate while stating that a phone microphone is not automatically a calibrated sound-pressure instrument, with a documented reference offset and adjustable calibration limited to plus or minus 10 dB.

A prototype could show a dramatic number and turn red above 85, but the app must not present an estimate as laboratory accuracy: it floors silence at negative 120 dBFS instead of negative infinity, smooths readings, stops capture when paused, and keeps audio in memory rather than recording or transmitting it.

The project has 34 unit-test methods across six files covering a 1 kHz full-scale sine, silence, 100 Hz attenuation, invalid FFT sizing, calibration boundaries, trial expiry, and purchase precedence, while UI tests cover meter controls and the expired-trial path; a demo does not need that, but a paid App Store product does.

Confusing the two postpones product work until users depend on it and every correction risks their trust, while the bill becomes exceptions, refunds, support messages, and fear of touching the code.

The build should answer one question at a time

Before a prototype sprint, ask for the decision it must make; before an MVP, ask what the first real user can rely on.

If nobody may care, build the smallest believable prototype with fake data, a short flow, and lies in writing, then let it persuade people or fail quickly.

If people may return, pay, trust it with files, or hand it to a colleague, build an MVP: cut features hard, but keep persistence, ownership, recoverable operations, and promise-bearing failure paths, because manual back-office work is acceptable early while silent data loss is not.

Make the transition explicit: at the sprint's end, review what changed, write launch scope from that evidence, and decide whether prototype code is reference, reusable visual asset, or liability, because usually it is reference.

MVP development cost covers the budget difference once you have made that decision; if the product is underway but you need to judge whether the work can be trusted, read my technical due diligence checklist.

I build and repair products from the first uncertain demo through to the part people depend on, and my CV and rate are here.