软件上线后维护要花多少钱：DACH SaaS 基准
上线并不会结束软件预算。它只是改变预算的形态。上线前，钱买的是 discovery、实现、QA 和部署。上线后，钱买的是连续性：bug 修复、依赖和框架升级、云和可观测性、安全、合规、支持、产品迭代以及紧急工作。
这篇文章刻意区别于我们的 定制软件开发指南。那篇回答构建成本。本文回答上线后的意图：一个 SaaS 产品上线后，每年软件维护成本是多少？
需要一份说得过去的维护预算？
规划运营模型基准答案
对 DACH SaaS 产品，如果产品仍在演进，每年大约应预算原始构建成本的 18-30%。安静、低风险的内部工具可能接近 10-16%。受监管、集成密集或快速增长的 SaaS，在合规、支持、安全和产品迭代都活跃时，可能达到 35-60%。
在我们对 2023 至 2026 年中维护过的 24 个 DACH SaaS 与 SaaS-like 产品的方向性基准中，第一年维护支出的中位数是原始构建成本的 24%，第二年是 21%，第三年是 26%。第三年的上升不是因为软件到生日就会自然腐烂，而是因为框架大版本、云增长、积累的产品需求、合规证据、安全发现和已经变得业务关键的集成。
| 上线后年份 | 年度支出中位数 | 中间 50% 区间 | 若构建成本 EUR 150k | 常见驱动因素 |
|---|---|---|---|---|
| 第 1 年 | 构建成本的 24% | 16-34% | EUR 36k | 上线缺陷、支持、可观测性、安全基础、第一轮产品迭代。 |
| 第 2 年 | 构建成本的 21% | 13-31% | EUR 31.5k | 上线 bug 减少、客户支持增加、依赖升级、可衡量的产品工作。 |
| 第 3 年 | 构建成本的 26% | 15-40% | EUR 39k | 大版本升级、合规证明、扩展成本、集成漂移、架构清理。 |
什么算软件维护？
ISO/IEC 的维护语言把维护分为纠错、适应、完善和预防。放到真实 SaaS 预算里：纠错工作修 bug；适应工作让产品在浏览器、API、设备和法律变化时仍可用；完善工作改善产品和可维护性；预防工作降低未来风险。现实里，一个 ticket 往往同时跨越几类。
| 预算项 | 包括什么 | 不包括什么 |
|---|---|---|
| Bug 修复 | 生产缺陷、回归、数据边界情况、失败工作流。 | 伪装成 bug 的大功能。 |
| 依赖和框架升级 | 包、runtime、数据库客户端、SDK、破坏性框架迁移。 | 出于偏好的重写。 |
| 云和可观测性 | 托管、日志、指标、trace、告警、备份、可用性检查、成本复查。 | 无人负责的云账单。 |
| 安全 | 漏洞修复、密钥轮换、访问复查、SAST/SCA、渗透测试修复。 | 一年一次的打勾活动。 |
| 合规 | GDPR 请求、DPA、审计证据、保留策略、AI Act/CRA/NIS2 准备。 | 单纯法律建议。 |
| 支持 | 技术分诊、用户问题、管理请求、事故沟通、交接文档。 | 客户成功战略。 |
| 产品迭代 | 小改进、UX 修复、报表、流程打磨、转化改善。 | 新的产品线。 |
| 紧急工作 | 宕机、供应商事故、紧急安全修复、数据修复、回滚。 | 被叫作紧急的普通 roadmap 压力。 |
第一、第二和第三年拆分
| 项目 | 第 1 年 | 第 2 年 | 第 3 年 | 为什么变化 |
|---|---|---|---|---|
| Bug 修复 | 4.0% | 2.5% | 3.0% | 上线 bug 下降，但较旧集成会制造新边界情况。 |
| 依赖和框架升级 | 2.0% | 3.0% | 5.0% | 小升级若被推迟，会变成大版本工作。 |
| 云和可观测性 | 4.0% | 4.0% | 5.0% | 使用量、日志、保留和监控深度随采用增长。 |
| 安全 | 3.0% | 2.5% | 3.0% | 第一年建立基础，后续修补供应链和访问漂移。 |
| 合规 | 2.0% | 2.0% | 3.0% | 产品成熟后，客户和监管要求更多证据。 |
| 支持 | 3.0% | 3.0% | 4.0% | 更多用户意味着更多分诊、管理和文档工作。 |
| 产品迭代 | 5.0% | 3.0% | 2.0% | 早期反馈密集；后续迭代常进入单独 roadmap 预算。 |
| 紧急工作 | 1.0% | 1.0% | 1.0% | 小额储备避免每次事故都变成采购讨论。 |
| 总计 | 24.0% | 21.0% | 26.0% | 用下方计算器调整。 |
交互式维护成本计算器
这是面向 board 的第一版估算。它从基准出发，根据产品类型、合规压力、使用量、支持负载和技术债调整。
依赖、云、安全、合规和支持
现代 SaaS 不是纯自研代码。它是供应链：框架、包、SDK、构建工具、容器镜像、云服务和 API。ITPro 报道的 Sonatype Log4j 数据显示，Log4Shell 多年后仍有易受攻击版本被下载，即使修复版本已经存在。核心教训很直接：如果没有人明确拥有依赖维护，漏洞就会留下。
云和可观测性也不是可选项。流量、日志、trace、指标、存储、备份、队列、邮件、搜索、AI API 和监控会成为经常性成本。安全和合规是生命周期工作：GDPR 已适用；NIS2、Cyber Resilience Act 和 EU AI Act 会因产品与行业不同而增加证明压力。支持则把隐藏维护变成可见信号。
避免吞掉构建成本关键词
构建成本指南回答：创建产品要花多少钱？这篇维护基准回答：产品已经存在后，让它继续有用要花多少钱？小型流程改进、UX 修复、报表和转化改善属于维护。新模块、新 persona、新定价模型，或在 web 产品旁边再做移动 app，通常属于单独 roadmap 预算。
商业路径是：用 定制软件开发 完成构建，用 软件 QA 管住回归与信心，用 Fractional CTO 建立运营节奏、架构判断和供应商 accountability。
来源与基准说明
本文基准来自 Wavect 对 24 个匿名 DACH SaaS 与 SaaS-like 产品的观察，并结合维护分类、软件供应链风险和欧盟监管压力的外部证据。它是方向性基准，不是代表性市场调查。维护分类可参考 ISO/IEC/IEEE 14764 与 SWEBOK。供应链风险可参考 ITPro 对 Sonatype/Log4j 的报道 以及 arXiv 上的 SLSA 研究。欧盟义务请核对 GDPR、NIS2、Cyber Resilience Act 和 EU AI Act。云与可观测性价格请在预算前核对 AWS CloudWatch、Datadog 和 Sentry。
最终思考
健康的 SaaS 维护预算不是模糊 retainer，而是上线后的运营模型，包含具名项目：bug、依赖、云、可观测性、安全、合规、支持、产品迭代和紧急工作。对仍在演进的普通 SaaS，每年 18-30% 的原始构建成本是一个可辩护的起点。
请把构建预算、维护预算和 roadmap 预算拆开。混在一起，就会出现经典的上线后惊讶：所有人都以为产品已经完成，而软件早已变成一个带有用户、依赖、法律和事故的活系统。
想把这个基准变成你的维护计划？
联系 Wavect构建产品，而不只是 backlog
如果这篇文章对应的是一个真实产品决策，Wavect 可以用高级创始人级判断帮你界定范围、构建、加固或领导软件工作。
可选服务路径：