宁波小程序开发售后维护：年费之外的技术支持与升级成本

小程序签合同那天，多数老板问的是「做完多少钱」；一年后才发现，真正让预算失控的是「做完之后每年还要花多少」。开发费是一次性的，维护费是长期的，而后者往往在合同里写得很模糊。

这篇文章不谈开发报价，只谈上线之后的事：年费之外还有哪些成本，哪些该花、哪些可以省、哪些必须在合同里提前写清楚。

先把年费拆开：固定支出和浮动支出

常见的「年费」其实是一笔打包价，里面混着几项性质完全不同的费用。谈价格之前先把它拆开，才知道哪些是硬性支出，哪些是服务费。

• 微信小程序认证费：每年一次，由平台收取，金额固定，跟服务商无关。
• 域名与服务器：域名按年续，服务器按配置和带宽计费。商城类小程序流量上来后，配置可能需要调高。
• SSL 证书：多数场景有免费方案，但部分支付或接口场景要求付费证书。
• 第三方接口费：短信验证码、物流查询、电子面单、地图定位等，按调用量计费，用量小的时候几乎可以忽略。
• 服务商维护费：这部分才是真正有谈判空间的内容，也是纠纷高发区。

前四项基本是「交给平台的」，第五项是「交给人的」。老板们容易把整笔年费当成服务商收的，其实里面有相当一部分并不进服务商口袋，谈价时要分开看。

技术支持到底包含什么，别只看「免费维护一年」

「免费维护一年」这句话几乎是行业通用话术，但它的内容差别极大。签约前至少要问清楚四件事，最好写进合同附件。

1. 响应时效怎么算：是工作时间响应还是 7×24 响应；是电话接通算响应，还是问题解决算响应。餐饮这类有营业高峰的行业，晚上和周末出问题没人管，损失是实打实的。
2. 故障范围怎么界定：程序报错、支付不通、页面打不开算故障；那「客户说不好用」「想改个按钮颜色」算不算？多数纠纷出在这里。
3. 修改次数有没有上限：小改动的次数是否封顶，超出后按什么标准计费。
4. 属于谁的责任：因为客户自己改了后台配置、误删数据导致的问题，是否在免费范围内。

一个务实的做法是：把「故障」和「需求」分开写。故障是系统没按设计运行，服务商负责；需求是业务想加新东西，另行报价。这条界线不划清，免费的维护期会变成扯皮期。

版本升级与规则跟进：最容易被低估的一块

小程序不是做完就静止的。微信平台会调整接口规范、审核规则、用户隐私授权方式和支付相关要求，这些变化不会提前很久通知，但会影响线上运行。

比如隐私协议弹窗、用户信息授权方式、支付回调规则，历史上都做过调整。服务商如果不管，小程序可能在某天审核被拒，或者某个功能悄悄失效。这类工作的成本通常不出现在年费清单里，谈合同时要单独问：

• 平台规则变化导致的适配，是否包含在维护费内；
• 基础库升级、依赖组件更新由谁执行；
• 系统本身的版本迭代（比如订单流程优化、后台功能增强）是否收费、按什么方式计。

行业里的常见做法是「规则适配包含、功能迭代另计」。这个划分算合理，但前提是写下来。口头承诺在人员流动之后基本等于没有。

三种维护模式的成本差异

企业拿到的维护方案，大体是三选一，成本结构完全不同。

• 按年打包：一年一笔固定费用，含故障处理和小幅调整。适合需求稳定、自己不养技术人员的门店。缺点是超出范围的工作容易被推诿。
• 按次计费：不付年费，出问题按工时或按次结算。适合小程序只是辅助工具、几乎不改动的企业。缺点是紧急故障时排期不确定，可能排在别人后面。
• 自建或半自建：源码交付后自己找人维护，或由内部人员兼管。前提是拿到了完整源码和部署文档，否则无法接手。

没有哪种绝对更好。连锁门店多、订单量大的，按年打包更稳；一年只做展示、几乎不更新的，按次更省钱。关键是选择之前，先知道自己一年大概会提多少次修改需求。翻一下过去半年的沟通记录，大致就有数了。

签合同前的可执行清单

与其上线后再补维护条款，不如在开发合同里一次写清。下面几条可以直接拿去对照：

1. 让对方列出年费的逐项构成，区分平台收取和服务商收取，白纸黑字。
2. 约定故障响应时效，并按严重程度分级，写清各级的响应与解决时限。
3. 明确「故障修复」与「功能新增」的界线，以及小改动的免费次数。
4. 约定源码、数据库和部署文档在什么节点交付，与付款节点挂钩。
5. 写清平台规则适配由谁负责，是否额外收费。
6. 维护费按年支付而非一次付多年，保留后续议价空间。

维护成本本身不可怕，可怕的是没算进去。同样一笔钱，提前写进预算就是可控支出，临时被通知就是意外亏损。上线前多花半小时把这几个条款敲定，比事后争论一整天有用。