一个新软件产品，未来 12 个月要花多少钱？

在想法阶段，一个新软件产品往往看起来很便宜：代码可以在现有的笔记本上开始写，免费套餐可以托管原型，大部分工具本来就在信用卡账单上。

只有把这个想法放到时间线上，成本才会变得清楚：免费套餐可能到期，开发者账号每年续费一次，上线素材集中在某一个月，而一个已有的设计或 AI 订阅还要多支撑一个产品。

12 个月的产品成本计划不需要是一套完整的财务模型。它需要一个一致的边界、一份时间安排，以及清楚区分“你已经在付钱的资源”和“这个项目可能新增的支出”。

先想清楚这份计划要回答什么

用成本计划回答一个有边界的问题：

如果我在这些假设下推进这个产品 12 个月，哪些成本属于这份计划？它们预计在什么时候发生？

这个问题比“这是不是一门好生意？”窄得多。除非你在单独的视图中加入，它不包括需求、收入、价格、税费、融资，也不包括创始人时间的价值。

把问题限定得窄一些，可以避免一个常见的表格问题：一张表慢慢变成了预算、现金流量表、销售预测、盈利模型和上线清单，却没有一个视图有清晰的定义。

在最上方写下计划的起始月份和时长。12 个月很有用，因为它至少能覆盖大多数年付服务的一次扣费，但它不是必须的。一次三个月的验证，可能只需要三个月的计划；一个周期很长、受监管的上线，可能需要 18 或 24 个月。

把成本分成三组

先分成三组，而不是一张不加区分的支出清单。

1. 产品可能占用的已有资源

这些是产品组合已经在付费的服务：设计套件、代码托管套餐、AI 助手、监控账户、记账服务或共用的托管平台。

选定计入计划的份额。如果一个每月 $20 的设计工具可能有一半时间用于新产品，那么计划份额就是每月 $10。

这是一种成本归属，不一定是新增的现金支出。无论新产品是否启动，产品组合可能仍然每月支付 $20。让这一组保持可见，可以帮你了解产品占用了多少资源，又不会把每一美元归属都说成新增支出。

如果难点在于如何分配共用资源，共同 SaaS 成本分摊指南介绍了平均、按收入、按用量和自定义几种方法。上线前的计划通常需要一个简单的自定义份额，因为它还没有产品收入或用量历史。

2. 新增的周期性成本

这些是项目推进后预计会开始的服务：新的托管套餐、数据库、邮件服务、授权 API、客服工具或产品专属订阅。

记录金额、币种、周期、首次预计扣费日期，以及已知的停止时间。不要只写一个月度折算值。一个每年 $120 的账号和一个每月 $10 的服务，算术平均值相同，但扣费时间和取消决定都不同。

3. 新增的一次性成本

可能包括域名购买、上线用的美术素材、安全审查、外包里程碑、设备或一次性购买的数据集。

把每笔成本放在预计发生的月份。不要只是为了让图表更平滑就把它平摊。如果时间不确定，就写下假设，或比较两种安排。

想看更完整的经营成本清单，可以读《同时经营多个软件产品，真实成本是多少》。

先排时间表，再算平均值

假设一个虚构的产品叫 Focus Notes，计划从 2026 年 8 月开始，为期 12 个月。

假设如下：

• 一个已有的每月 $20 设计工具，占用其中 50%；
• 新的云托管，每月 $24；
• 第一个月的上线素材，$96。

整个周期的合计很直接：

现在把这些金额放到时间表上。

第一个月是 $130，之后每个月是 $34，合计正好是 $504。

算出这个总额之后，再推导平均值：

$504 ÷ 12 = 月均成本 $42

这个平均值适合用来把这份计划和一个 6 个月或 12 个月的备选方案做比较。它并不是在预测信用卡每个月会被扣 $42。

年度成本也用同样的方法

假设 Focus Notes 还需要一个每年 11 月续费的 $99 开发者会员。把 $99 放在 11 月，而不是在每个月都加 $8.25。

修改后的 12 个月总额变为 $603，用于比较的月均值变为 $50.25。但预计的月度分布仍然不均匀：

• 8 月：$130；
• 11 月：$133；
• 其余十个月：各 $34。

这种处理保留了预计的现金时间点，也让一个实际问题变得可见：到年度服务续费时，这个产品还在运营吗？什么时候必须决定是否续费？

你也可以保留一个摊销后的经营视图用于其他分析。只要清楚标注，不要用它替换按预计扣费排出的时间表。一个数字说明服务期内的成本，另一个说明现金什么时候可能流出。

对不确定的用量成本使用区间

有些产品成本不是固定的。存储、模型推理、邮件、地图、媒体处理和支付手续费，都可能随用户行为增长。

不要把这种不确定性藏在一个看起来很有把握的金额里。建一个小区间：

保持其他非用量假设不变，然后比较这三个总额。目的不是预测准确的请求数，而是看在一个合理区间内，决定是否会改变。

如果这份计划只有在低场景下才可以接受，那么这项不确定的成本就值得在上线前先测量，或者先设置技术上限。如果三种场景都可以承受，更细的预测可能并不能改善决定。

说明：MarginDeck 是我开发的。本文介绍的是我自己在这个产品上的工作。

MarginDeck 1.2 为每一项计划成本保存一个选定的金额，而不是一整套场景系统。当两种差别很大的成本结构都值得保留时，你可以分别保存成两份计划，但这个功能并不以概率预测的形式呈现。

保持币种独立

如果产品同时使用美元计价的托管服务和欧元计价的外包，除非计划定义了汇率规则，否则保持分别合计。

一条有用的换算规则至少需要：

• 汇率来源；
• 汇率日期或平均区间；
• 报告币种；
• 何时更新汇率的决定。

没有这样的规则，把 500 美元和 300 欧元相加并不是一个总额，只是两个去掉了单位的数字。

对小型计划来说，分别显示两种币种通常就够了。做决定的人可以看到各项义务，而不会把一个临时的汇率假设误当成稳定的产品成本。

给假设做快照

一份计划应该能在以后被复盘。记录做计划时使用的价格和时间安排，而不是让每个单元格都链接到实时的供应商页面，或自动替换成产品组合里的最新数值。

再加一个轻量的复审流程：

1. 标出哪个假设变了。
2. 在备注或版本中保留之前的数值。
3. 决定当前计划是否采用新数值。
4. 重新计算总额，并解释重大差异。

这样可以避免一个共用工具涨价时，悄悄改变一份已经被批准进一步研究的计划。

MarginDeck 的新产品成本规划对已有成本就采用了这种方式：它把记录中的时间安排复制进计划。如果来源成本发生变化，计划可以标识出这种状态，但在用户明确刷新之前，会一直保留已保存的假设。计划份额只存在于计划中。

完整的产品行为，请看更新日志中的 MarginDeck 1.2：开始新产品前，先算算成本。

在现金计划旁边加上经营者时间

对独立开发者来说，现金成本并不是全部投入。在计划旁边估算经营者时间，但不要不加标注地把它混进服务账单。

例如：

这个时薪是决策假设，不是工资，也不是客观的市场价格。选一个能代表你时间替代用途的数值；如果结果会左右决定，就多试几个时薪。

把现金和经营者时间并排放置，能得到两句有用的话：

• “这份计划安排了 $603 的产品成本，包括开发者会员。”
• “按当前的工作估算，它还可能需要 286 小时。”

这比把所有东西合并成一个没有解释的“预算”清楚得多。

不要只是为了填满表格而加上收入

在没有收入证据之前，成本计划也可以很有用。因为表格看起来不完整就加一个销售预测，只会制造虚假的平衡。

如果你有关于价格、转化、留存或已签约客户的证据，就另建一个收入场景并注明来源。然后用一个定义清晰的指标，例如贡献利润，把收入和成本连起来。

如果没有这些证据，就保留成本计划，并写下需要验证什么。这份计划仍然可以设定一个实验边界，例如：“在完成五次用户访谈和一次付费试点之前，花费不超过 $600 和 120 小时。”

可以反复使用的规划清单

接受结果之前，确认：

• 起始月份和计划时长与决策窗口一致。
• 已有资源和真正新增的支出已经分开。
• 每项已有资源都有明确的计划份额。
• 月付、年付和一次性成本都按预计的时间安排。
• 不会持续整个计划周期的服务，已包含停止日期。
• 一次性的上线和审查成本没有被隐藏。
• 对用量敏感的服务有区间，或有记录的常规假设。
• 没有在缺少换算规则的情况下把不同币种相加。
• 总成本等于各月计划金额之和。
• 月均成本标注为平均值，而不是每月扣费。
• 经营者时间在单独的视图中可见。
• 收入和成功预期只在有单独证据支持时出现。

当另一个人（或三个月后的你）能根据这些假设还原出结果时，这份计划就准备好了。

用计划确定下一个决定

计划的产出应该引出一个行动。你可能会精简初始工具、在验证完成前推迟一笔年度购买、设置用量上限、复用已有服务，或者决定做一个三个月的实验比投入十二个月更合适。

说明：我是 Junhua，MarginDeck 的开发者。我做新产品规划功能，是因为我想在不把假设中的产品和成本加入正式经营数据的前提下，检验成本假设。MarginDeck 可以把这些计划保存在本地 Mac 上，但同样的方法也适用于电子表格：保留时间安排，展示假设，别让估算假装成实际扣款。