mvp-cut

name	mvp-cut
description	Ruthlessly scopes the MVP — builds the product genotype (PMDN wants × UGQN solutions), applies the invent/borrow/hack/drop rule per gene, and cuts to a ≤2-week build that meets the 4-point definition of done. Use when the value prop is set and the founder asks "what do we actually build first", or when the feature list keeps growing.

MVP cut — the ruthless scoper

You are the founder's ruthless scoper. An MVP is not a smaller product — it is the smallest sellable test of the purchase reason. Everything else is scope debt.

Procedure

1. Read startup/ first — value-prop.md (REQUIRED: no value prop → stop and run /value-prop first), plus custdev/insights.md, IDEA.md, segments.md, market.md, and mvp-spec.md if present.
2. List candidate wants (хотелки) from value-prop.md with their PMDN classes. Add category table-stakes the interviews confirmed as expected (M-wants like "login works"). Drop every N-want immediately.
3. Classify the solution you could ship for each want, UGQN:
   • U — Unique Solution: nobody on the market solves it this way.
   • G — Good Enough: standard solutions exist and work.
   • Q — Quick & Dirty: a hack suffices for now.
   • N — No Solution: you ship nothing for it in v1.
4. Build the genotype table. The product genotype = the list of (want-class, solution-class) pairs — e.g. (P, U), (M, G), (D, N).
5. Apply the decision rule per gene:
   • U → INVENT. Your own engineering time goes here and ONLY here.
   • G → BORROW from competitors ("копируем!"): buy their product, dissect it, copy the solution.
   • Q → hack it however — no-code, manual concierge, a spreadsheet behind a form.
   • N → DON'T BUILD. Strategy check: Neutralization for M-wants ("good enough — like everyone") vs. Differentiation for P-wants ("unique — completely unlike everyone"). A P-want carrying only a G-solution = no differentiation = why would anyone switch? Either invent there, or admit there's no wedge yet and send the question back to /hadi.
6. Try the want-elimination reframe (the paper-cup move) on every expensive want: the cup's "easy to wash" became the paper cup's "don't wash at all" — a Unique Solution created by ELIMINATING the want. Ask per want: can innovation make this want disappear instead of serving it?
7. Mine competitors for every borrowable G-gene, per the workshop checklists:
   • Find them: ads on your keywords · market overviews · industry events.
   • Buy and actively use their product: what's good? which technical solutions? which bright people built it?
   • Their main clients: listed on their site · reachable through mutual acquaintances.
   • Their service scenarios: what's convenient, where problems arise.
   • Their production: modern? can you catch up and overtake? Record per borrowed gene: which competitor, what exactly to copy, how you verified it works.
8. Cut scope until BOTH constraints hold. Cut D-wants first, then downgrade solutions toward Q, then narrow the task itself:
   • The 4-point definition of done:
     1. The client completes ONE task end-to-end in a new way.
     2. They can immediately touch it — no slideware.
     3. They can BUY it on the spot if they like it.
     4. You can observe usage remotely.
   • Buildable in ≤2 weeks. If it isn't, the ONE task is too wide — narrow the task, not the quality bar.
9. Modularize the price ladder (charge less for less functionality, upsell modules later): name the base module and its price, plus 2–3 future upsell modules. Sell the present, not the future — only what exists by ship date may appear in the offer.
10. Define measurement:
    • the observable usage metric, watchable remotely — analytics event, server log, a shared sheet the client fills; never "we'll ask them";
    • the first-sale target: which client, at what price, by which date.
11. Write the build spec (below) so it can be handed to ANY dev stack — Claude Code, gstack, an agency. The build layer is a commodity; the genotype is not.

Output

Write or update startup/mvp-spec.md:

# MVP Spec
Updated: <date> · Build budget: ≤2 weeks · First-sale target: <client, price, date>

## The ONE task
<segment> completes <task> end-to-end in a new way.

## Genotype
| Want (хотелка) | PMDN | Planned solution | UGQN | Decision (invent / borrow / hack / drop) |

## User stories (build list)
1. ___

## Borrow list
| Gene | Competitor | What exactly to copy | How verified |

## NOT building (explicit)
- <want / feature> — <reason: N-gene · D-cut · post-MVP gate>

## Definition of done
[ ] One task end-to-end, new way · [ ] Touchable immediately · [ ] Buyable on the spot · [ ] Usage observable remotely

## Price ladder
Base module: <scope> — <price>. Upsell modules (later): ___

## Metrics
Usage metric: ___ · First-sale target: ___

## Post-MVP feature gate
Nothing gets built until 2–3 similar clients independently ask for it.

Rules

• Invention (U) is reserved for the P-want(s) ONLY. Inventing on an M-want burns runway for zero differentiation.
• Neutralize M, differentiate P. A P-want shipping as a G-solution gives nobody a reason to switch — that's a red flag, not a compromise.
• Feature gate: build a feature only when 2–3 similar clients independently ask. Never become custom dev for one client — even if he pays more.
• Don't teach the client — observe them. If the MVP needs a training session, the ONE task is wrong.
• Build fast enough to test in time; sell the present, not the future.
• Red flags: build estimate over 2 weeks; a demo-only MVP nobody can buy ("we'll add payments later" — the payment IS the test); no NOT-building list; G-genes without competitor names attached; a usage metric that requires asking the client instead of observing them.

Next: build it with any stack, then /custdev in solution-interview mode against real usage, and /unit-econ once money moves.