小程序外包合同避坑指南

去年帮朋友看一份小程序外包合同，甲方是他，乙方是某工作室。合同三页纸，核心内容只有一句“开发一个电商小程序，工期两个月，总价四万八”。我问他：功能清单在哪？验收标准是什么？源码归谁？他愣了半天说，对方讲“都是这么签的”。

后来这个项目拖了五个月，上线时少了三个功能，源码也没拿到。这类事在独立开发者和中小甲方之间反复上演。今天不谈法律理论，只讲我在实际项目里踩过的坑和后来固定下来的合同写法。

先搞清楚：你签的到底是什么合同

市面上常见的“小程序制作合同”大致分两类，条款结构完全不同：

• 委托开发合同：乙方按你的需求从零写代码，著作权归属、源码交付是核心。
• SaaS/模板服务合同：你买的是账号使用权，代码不在你手里，合同本质是服务协议。

很多纠纷的根源是：甲方以为签的是前者，拿到的却是后者。签约前让对方明确写一句“本项目为定制开发，非模板套用”，比什么都管用。

需求附件比正文重要十倍

合同正文写得再漂亮，如果功能描述只有“电商小程序一个”，等于没写。我的做法是：正文只写框架，把功能清单做成附件，逐条编号。

附件一：功能清单（节选）
1. 商品模块
   1.1 商品列表（分页加载，每页20条）
   1.2 商品详情（含规格选择、库存显示）
   1.3 搜索（按名称模糊匹配）
2. 订单模块
   2.1 购物车（增删改、批量删除）
   2.2 下单（微信支付，含退款回调）
3. 后台
   3.1 商品上下架、库存修改
   3.2 订单列表与导出（CSV）

每条后面留一列“是否包含在报价内”。谈的时候可能觉得啰嗦，但真到验收阶段，这张表就是唯一依据。口头承诺的“这个顺手就做了”，不进附件就等于不存在。

付款节奏：别让尾款变成人质

常见的 5:5 或 3:7 分期看着合理，实际执行时问题很多。我建议按里程碑拆，并且把每个里程碑和可运行的交付物绑定：

• 签约付 30%，条件是需求附件双方签字确认；
• UI 定稿付 20%，交付设计稿源文件；
• 核心功能可演示付 30%，在测试环境跑通主流程；
• 验收上线付 20%，源码、数据库、部署文档全部移交。

关键点：每一笔钱对应一个可验证的东西，而不是“开发进度到一半”。进度是主观的，可运行的环境是客观的。

知识产权和源码，必须写死

这是最容易含糊的地带。合同里至少要出现这几句明确表述：

• 项目交付后，小程序前后端源代码、设计稿、数据库结构的著作权归甲方所有；
• 乙方不得将本项目代码、UI 用于其他客户项目；
• 乙方使用的第三方开源组件需列明许可证类型，不得引入会传染甲方代码的协议；
• 交付物包含完整可编译源码、依赖清单、部署说明。

见过一份合同写“乙方保留技术成果的使用权”，甲方还以为自己买了全部。使用权和所有权是两回事，别混。

验收标准要可执行

“功能正常、界面美观”不是验收标准。可执行的写法是：

甲方在收到交付物后 7 个工作日内，依据附件一功能清单逐项测试。存在功能性缺陷的，乙方应在 5 个工作日内修复；不影响主流程的界面细节问题，可列入上线后 30 天内优化。逾期未提出书面异议的，视为验收通过。

给异议设期限，对双方都是保护。否则甲方可以无限期拖着不验收，乙方也可以拿“你没说不行”当挡箭牌。

几个容易被忽略的条款

• 服务器与账号归属：小程序 AppID、微信支付商户号、云服务账号必须注册在甲方名下，乙方只拿协作权限。见过乙方用自己主体注册小程序，项目结束后甲方连后台都进不去。
• 上线后的维护期：明确免费维护多久、响应时间、修 bug 和加功能的边界。加功能另收费要写清楚。
• 延期责任：约定每日千分之几的违约金，同时给乙方一个合理免责范围（如甲方需求变更导致的延期）。
• 保密与数据：涉及用户数据的项目，写明数据不得导出、不得用于训练或其他用途。

写在最后

合同不是为了打官司，是为了让双方在项目中途有据可依。一份好的小程序制作合同，读起来应该像一份施工图：做什么、做到什么程度、什么时候交、交什么、钱怎么给，全部落在纸面上。

如果你是自己接单的开发者，也别嫌甲方要求细。把附件清单和验收条款主动写进合同，反而能筛掉那些需求永远在变的客户。省下来的扯皮时间，够多写两个项目了。