签小程序外包合同前，我踩过的坑

上周帮一个朋友看合同，他刚找外包公司做小程序，合同三页纸，我翻完只问了一句：验收标准写在哪？他愣了半天，说对方口头承诺“保证能用”。

这行干了七八年，我自己接过外包，也帮人审过合同。说句实在话，小程序外包合同这东西，大部分坑不是对方故意埋的，是双方都没想清楚就签了。等做出来发现不是想要的东西，再翻合同，发现里面全是“双方友好协商”这种废话。

先把“做什么”写死

合同里最容易糊弄过去的就是需求范围。很多外包合同只写一句“开发微信小程序一个”，然后就没了。什么叫“一个”？三个页面也叫一个，三十个页面也叫一个。

我的建议是把需求文档作为合同附件，而且附件要写到页面级别。至少包含：

• 页面清单和每个页面的功能点
• 后台管理端有哪些模块
• 用什么技术栈（小程序开发这块，原生还是 uni-app 差别很大，后期维护成本完全不同）
• 数据从哪来，要不要对接第三方接口

需求文档别嫌麻烦，写得越细，后期扯皮越少。我见过一个项目，合同里没写消息通知，做完之后甲方要加，乙方报价两千，两边都觉得对方不讲理。

验收标准：别写“正常运行”

“功能正常运行”这句话在合同里等于没写。什么叫正常？谁的手机算正常？

比较靠谱的写法是分两段：先功能验收，按附件需求清单逐条过；再稳定性验收，比如连续运行一周无严重 bug，主流程在主流机型上不崩溃。iOS 和安卓各测几台，写清楚型号范围，别到时候拿个五年前的旧机器说卡顿。

验收期和付款节点要绑在一起。常见的是 3:4:2:1，尾款留 10% 做质保金，验收后一个月付。这个比例可以谈，但尾款一定要留。

源码和账号归属，这条最容易忽略

我见过太多人做完小程序，源码拿不到，服务器账号在对方手里，想换人维护都换不了。

合同里必须明确：

• 交付物包含完整源码，且源码可独立编译运行
• 微信小程序的主体账号、开发者权限归甲方
• 服务器、域名、数据库等云资源账号归甲方，或至少甲方有管理员权限
• 第三方服务（支付、地图、短信）的密钥交付方式

还有一条，知识产权归属要写清楚。是买断还是授权使用，能不能二次开发，能不能转卖。这个不写，后面想拿去做个 App 版本都可能被卡。

变更和延期怎么算

需求变更是外包项目的常态，合同里不写变更流程，最后就是互相甩锅。

比较合理的做法是约定一个变更机制：小改动（比如文案、样式调整）包含在总价里，不额外收费；涉及新页面、新接口的，按工作量评估，双方书面确认后再做。评估标准可以约定按人天算，单价提前写进合同。

延期责任也要对等。乙方延期有违约金，甲方需求确认、素材提供、验收拖延，工期相应顺延。只约束一方的条款，签的时候对方可能不说，执行的时候一定会有情绪。

质保期和后期维护

小程序上线不是终点。微信基础库升级、支付接口调整、服务器续费，这些都会出问题。

合同里通常约定 3 到 12 个月的免费质保，范围是修复 bug，不包括新功能。这个要写清楚，不然甲方觉得啥都该免费改，乙方觉得啥都得加钱。

质保期之后的维护，可以约定按年收费或者按次收费，价格提前写个区间。别等到出事了再谈，那时候你没什么议价空间。

最后说两句

小程序开发这行，靠谱的团队和不靠谱的团队，合同水平差得很远。但合同不是用来防坏人的，是用来把话说清楚的。真到了要打官司的地步，几万块的项目，律师费都不够。

签之前花两个小时，把需求、验收、源码、变更这四块过一遍，比事后吵三个月有用得多。如果对方连需求文档都不愿意一起梳理，只催着签合同打款，那这个合作本身就该再想想。