2026 MVP 时间线基准：30 个真实软件 Build 到底花了多久

问“做一个 MVP 要多久”，有用的答案不是“三个月”。在我们 2026 年整理的 30 个匿名软件 MVP build 中，从签署 kickoff 到第一次 live release 的中位数是 12 个日历周。最快的项目 5 周进入受控生产试点，最慢的项目 26 周。差异很少来自框架，而是来自 scope 的形状：集成数量、移动端发布、决策责任、数据访问、合规问题和 QA 深度。

这篇文章只负责观察到的时间数据，不抢占完整 MVP 流程。如果你要找 build partner，先看我们的 MVP 开发服务。如果你要理解完整交付方法，看 软件开发流程指南。如果你要证据，可以看这些案例：PromptID、Twinsoft AI、Scramble Pay 和 Offlinery。

基准答案

一个可上线的软件 MVP 通常需要 10 到 14 周。小型内部工具需要 5 到 12 周。B2B SaaS MVP 需要 8 到 18 周。移动端或 Web 加移动端需要 12 到 26 周。AI MVP 需要 9 到 21 周，因为原型很快，但数据、评测、安全边界和人工 fallback 会把时间加回来。

样本定义和排除项

样本覆盖 2024 年 1 月到 2026 年 6 月完成的 30 个定制软件 build。每个项目都有真实用户或运营人员使用的 release、真实或接近真实的试点数据、必要的认证、部署、QA、handover 和上线决策。我们统计日历周，不统计人周，因为创始人和买方购买的是 time-to-market，不是 Jira 小时。

包含 B2B SaaS、内部 workflow 工具、portal、marketplace、移动 app 和 AI 产品。排除 no-code demo、纯设计原型、没有 build 的 strategy discovery、纯 QA rescue、纯智能合约审计、由 firmware 或采购主导的硬件试点，以及首个 release 被埋在多年路线图里的 enterprise program。

按产品类型拆分

集成数量

一个系统只要需要独立 credentials、sandbox、schema mapping、webhook、rate limit、审批或生产依赖，我们就把它算作一个集成。Stripe checkout、Google sign-in、HubSpot sync、SAP export、LLM provider、vector database 和 app-store release 都是不同的时间风险。

移动端 versus Web

移动端不是因为 React Native、Flutter、Swift 或 Kotlin 慢才更久，而是 release surface 更大：定位、相机、后台行为、push、deep link、账号删除、privacy label、截图和商店文案。Google Play 提醒，某些账号 review 可能到 7 天或在特殊情况下更久；Apple App Review 也仍然是实际 release gate。

AI versus 传统 SaaS

DORA 2024 的提醒很有用：AI 可能提高个人生产力和 flow，但如果 delivery system 薄弱，也可能损害交付稳定性和 throughput。研究结果也并不一致：Google 一个 96 名工程师的 RCT 发现复杂 enterprise task 时间约减少 21%，而 2025 年一个 open-source RCT 发现成熟仓库里的资深开发者反而慢了 19%。我们的交付观察更窄：AI 让原型更快出现，但没有取消 discovery、QA、数据治理和上线工作。

Discovery、Build、QA 和 Launch 拆分

延误：客户、工程和平台

按延误天数看，客户侧约占 58%，工程侧约占 29%，第三方或平台约占 13%。最贵的客户延误通常不是“反馈晚了两天”，而是决策含糊：功能已经做完，后来被一个没有参加 discovery 的 stakeholder 重新解释。

如何使用这个基准

1. 先看平台。 Web-only MVP 常可按 8 到 12 周计划；移动端或 Web-plus-mobile 通常从 12 到 20 周起步，除非 scope 很小。
2. 先数集成，再数页面。 7 个页面加 6 个集成，比 20 个页面加 1 个数据库更危险。
3. Discovery 必须产出排除项。 v1 不说明什么不做，时间线就是假的。
4. 把 QA 当成阶段预算。 MVP 可以小，但在信任、钱、数据或安全相关位置不能没测。
5. 指定决策 owner。 每个集成、法律问题、文案块、workflow 例外和 launch asset 都需要 owner。
6. 把 AI 当作验证工作。 模型失败有业务成本时，要加 eval、fallback、logging 和人工 review。

来源和基准说明

这个 benchmark 基于 Wavect 的匿名交付记录和复盘，因此是方向性数据，不是具有统计代表性的行业调查。外部研究支持这种谨慎：一篇 MVP 软件工程实践的 systematic mapping study 指出，关于 MVP 技术可行性评估和工作量估算的研究仍然有限。DORA 也提醒，不同应用之间缺少上下文的比较容易误导。移动端发布请复查 Apple App Review 和 Google Play publishing guidance。AI 生产力背景见 DORA 2024、DORA metrics、MVP practices mapping study、Google AI productivity RCT 和 2025 open-source AI productivity RCT。