小程序定制开发合同：我踩过的五个坑

去年帮一个做餐饮的朋友看他的小程序外包合同，甲方是朋友公司，乙方是本地一家小工作室，合同总共两页纸，我翻完只问了一句：这项目你们打算怎么做验收？他愣住了。后来项目延期两个月，尾款扯皮，最后双方各退一步草草收场。这类事我见得太多了，所以今天不聊技术，聊聊「小程序定制开发合同」这件事——它比选框架、定架构更早决定项目生死。

合同不是形式，是项目的第一次需求评审

很多甲方签合同时只盯着总价和工期，把附件里的需求清单当成走过场。实际上，合同正文和需求附件的关系，相当于宪法和地方法规——正文定原则，附件定细节。附件里每一条功能描述，都应该能对应到一个可演示的页面或交互。我的做法是：需求附件里每个模块后面加一列「验收标准」，写清楚什么状态算完成。比如「订单列表页」不能只写「展示订单」，要写「支持按状态筛选、下拉刷新、空状态提示、分页加载每页10条」。这一列写细了，后面扯皮的空间就小了一半。

五个最容易出事的条款

1. 付款节点与交付物绑定

常见的「3-4-3」付款（签约30%、开发完成40%、上线30%）本身没问题，问题在于「开发完成」没有定义。建议改成按里程碑付款，每个里程碑对应一个可运行版本：

里程碑一：UI 设计稿确认 + 项目脚手架可运行（付款 30%）
里程碑二：核心业务闭环（登录、下单、支付沙箱）可演示（付款 40%）
里程碑三：提审通过、正式环境部署、源码与文档移交（付款 30%）

注意最后一条，源码移交必须和尾款绑定，而且要在合同里写明移交内容：完整代码仓库、数据库结构、部署文档、第三方账号（微信开放平台、支付商户号、云服务）的管理权限。我见过最离谱的案例是尾款付完了，乙方只给了一个打包好的体验版二维码，源码拖了半年。

2. 需求变更的处理机制

小程序项目几乎没有不变更的。合同里必须有一条：变更需双方书面确认（微信聊天记录也算，但要约定确认方式），并明确变更对工期和费用的影响计算方式。可以约定一个小额变更的免计额度，比如「单个变更工作量不超过 0.5 人天且累计不超过 2 人天的，不额外计费」。这样既保护甲方，也避免乙方被无数小改动拖垮。

3. 知识产权归属要写全

只写「源码归甲方所有」不够。要明确：著作权、UI 设计稿、文档、以及乙方为该项目专门开发的组件库归属。同时约定乙方不得将本项目源码复用于其他客户（除非是通用开源组件）。反过来，甲方也要注意乙方使用的第三方库、字体、图标的授权问题，避免上线后被投诉侵权。

4. 验收标准与异议期

验收条款建议写成：乙方提交验收申请后，甲方在 7 个工作日内完成验收或提出书面异议，逾期未提出视为验收通过。异议必须具体到功能点，不能笼统说「体验不好」。这条对双方都是保护，防止无限期拖验收。

5. 维护期与响应时效

上线不是终点。合同里要约定免费维护期（通常 3-6 个月）和响应时效，比如「严重故障 2 小时内响应，一般问题 24 小时内响应」。还要写清楚维护范围：是只修 bug，还是包含小功能调整。很多纠纷就出在「这个算 bug 还是算新需求」上。

给甲方的实操建议

• 签合同前让对方提供至少两个已上线项目的案例，并实际打开体验，重点看加载速度和异常状态处理。
• 需求附件用原型图或截图标注，比纯文字描述清晰十倍。
• 把「提审通过」写进里程碑，因为小程序审核被拒是常事，责任划分要提前说清。
• 保留所有沟通记录，重要决策走邮件或书面确认。

给乙方的提醒

别为了接单把工期压得太死。合同里的违约金条款要设上限（比如不超过合同总额的 20%），同时明确甲方配合义务的时限——比如甲方提供素材、账号授权延迟导致的工期顺延，必须写进合同。我见过乙方因为甲方迟迟不给支付商户号，项目卡了一个月，最后还被扣违约金，非常冤。

合同的价值不在于打官司时能赢，而在于让双方在项目进行中少一些「我以为」。

说到底，一份好的定制开发合同，是把「丑话」说在前面。它不浪漫，但能让你在项目延期、需求膨胀、人员变动的时候，还有一个可以坐下来谈的基准。写代码要 review，签合同也一样，花两个小时逐条过一遍，比事后吵两个月划算得多。