Janky MVP

Janky MVP is a rough minimum viable product that deliberately tests the important assumption while leaving most of the eventual product unbuilt. In Tony Xu on Building DoorDash from a Class Project into a Global Marketplace, PaloAltoDelivery is the source’s example: eight PDF menus, a Google Voice number, founders answering calls, founder pickups, and a Square reader at the door.

The point was not to simulate the final DoorDash experience. The point was to test one question: whether consumers wanted delivery from restaurants that had never offered it. The first order and repeat Stanford-area usage became early Customer Pull before the company had marketplace software.

Bill Clerico on WePay, YC, and Fire Tech adds a payments version through WePay. The early product recorded payments in a UI while Bill Clerico later logged into the bank account to move money manually. That was not a scalable payments system, but it let the founders test whether groups and clubs would actually route money through the product.

Kyle Vogt on Justin.tv, Twitch, Cruise, and Choosing Hard Problems adds a hard-tech version through Cruise. Kyle Vogt’s early retrofitted Audi did not solve full autonomy; it showed a narrow highway lane-keeping wedge that helped make self-driving legible as a startup problem. The case is closer to Hard Problem MVP Scoping than to a simple landing-page test because the demo still needed real sensors, software, and vehicle integration.

Key Claims

• A rough MVP is useful when it isolates a demand question that would otherwise be hidden beneath engineering, branding, or operational complexity.
• Manual fulfillment can be acceptable in a first test if the founder is clear about what is being learned.
• Payment friction, phone calls, and founder labor do not invalidate a test when customers still complete the behavior.
• A janky MVP is not a license to ignore operations; the manual work should reveal what the later system must automate or redesign.
• The pattern complements Fast Product Validation and Validated Learning because it turns a vague idea into observable customer behavior.
• In regulated products, a janky MVP may validate behavior while leaving the most difficult compliance, fraud, and reliability work still ahead.
• In hard tech, a rough MVP may validate a technical wedge and investor narrative while leaving safety, manufacturing, capital, and regulatory risk unresolved.

Connections

• PaloAltoDelivery, DoorDash, and Tony Xu - source case.
• Customer Discovery By Doing Work - field discovery that preceded the MVP.
• Three-Sided Marketplace Validation - broader marketplace validation that followed.
• Customer Pull, Product Led Willingness To Pay, Fast Product Validation, and Validated Learning - adjacent validation concepts.
• WePay, Bill Clerico, and Payments Infrastructure Pivot - payments case where manual transfers preceded infrastructure.
• Cruise, Kyle Vogt, Hard Problem MVP Scoping, and Hard Tech Fundraising - autonomous-driving case where a narrow demo made a difficult category pitchable.