一人公司做 MVP，最容易失控的地方不是开发能力，而是交付边界。客户说“顺便再加一点”，创业者也常把一次试做变成定制项目，最后交付成本超过报价，既无法验证需求，也无法形成可持续的服务。MVP 的核心不是把产品做得简陋，而是在有限投入下，只交付能够验证核心价值的最小结果。

先定义“交付完成”

开始之前，应把客户购买的结果写成一句可检查的话：这次只帮助哪类客户解决哪个具体问题，并通过什么形式交付。边界至少要明确四件事：包含什么、不包含什么、客户需要提供什么、何时算完成。

例如，提供一次诊断或一份方案时，交付内容可以限定为问题梳理、重点建议和一次反馈沟通；不包含持续执行、额外场景适配和无限次修改。客户若未按约定提供资料，交付时间也应相应顺延。没有这些约定，“满意”就会变成无穷无尽的修改要求。

用结果限制功能

MVP 不应围绕“还能增加什么功能”设计，而应围绕“客户必须获得什么变化”设计。一个手工完成的服务、模板、报告或预约制体验，都可以成为最小方案，前提是客户能真实体验核心价值。

判断某项内容是否应纳入交付，可以问三个问题：它是否直接影响核心结果？客户是否已经明确需要？删掉它会不会导致方案无法验证？如果答案不明确，就先放入候选清单，而不是默认承诺。

把变更当成商业信号

客户提出新增要求，并不一定意味着必须立即满足。先判断它属于哪一类：核心问题未解决、原有范围表达不清，还是新的需求。前两类需要修正交付；后一类则应单独记录，必要时重新报价、调整时间或安排下一轮测试。

一次 MVP 交付结束后，还要复盘实际耗时、客户参与成本、修改次数和最终结果。如果每次都依赖临时加班才能完成，说明边界、价格或交付方式需要调整。只有当范围足够小、结果能够验收、过程可以重复，MVP 才真正具备验证和迭代价值。