开发合同怎么签？盯死这四件事

先说结论：合同的核心是「把模糊的写清楚」

开发合同纠纷，九成不是谁耍赖，而是签约时有些事没写清：功能做到什么程度算做完、钱分几次为什么付、验收按什么标准、东西最后归谁。

这四件事写死了，合作就有了基准，谁也不用猜。下面逐条说怎么写。

一、功能清单必须逐条进合同

「做一个商城小程序」不是需求，是一句广告。合同里必须附一份逐条列明的功能清单：每条做什么、不做什么、验收标准是什么。

清单有三个作用：

• 对客户：你知道钱花在哪些地方，也能判断哪条其实可以不做；
• 对服务商：范围清晰，才不会在过程中反复确认、反复报价；
• 对双方：任何「这个也要做吗」的争论，回到清单就能裁决。

特别注意清单里要写不包含什么。范围划得越清，中途加价的空间越小。我们自己的承诺是：清单内需求不做二次收费，中途新增范围重新报价、且必须签字确认再开发——这条同样要写进合同，才对双方都有约束力地成立。

二、付款节点卡「签字确认」，不卡时间

「按月付」对客户不利：时间到了东西没做完，款已经付出去了。

合理的结构是按确认节点分三期。以我们合同的标准结构为例：

每一次打款之前，都有一个需要客户签字的确认节点——付第二期前你看过原型，付第三期前你验收过跑得起来的版本。

顺便说一条：我们不接受一次性付全款。业内要求开工前付清全款的，建议客户一律谨慎。

三、验收标准要可执行

「验收合格后付款」这句话等于没说——什么叫合格？

可执行的验收标准长这样：

• 功能对照：逐条对照功能清单演示，通过或不通过当场记录；
• 缺陷分级：致命缺陷（数据丢失、支付算错）零容忍；一般缺陷约定修复时限；体验优化建议不阻塞验收；
• 维护期起算：验收通过之日起算缺陷维护期。我们是 30 天，开发原因产生的缺陷免费修复；紧急问题 2 小时内响应、24 小时内给出方案。

把这三条写进合同，「验收」就从扯皮变成了核对。

四、源码和账号归属，白纸黑字

交付时客户应该拿到什么，合同里要列全：

• 完整源码：前端、服务端、数据库结构；
• 部署文档与账号信息：服务器、域名、微信平台、支付商户号等第三方服务的管理员权限；
• 知识产权归客户；服务商不做代码加密、不绑定服务器。

后两条是防「软绑架」的：代码加密或绑定特定服务器，客户就被锁死在这家服务商身上，第二年续费涨价只能认。写进合同，客户随时可以换团队接手。

签约前五分钟核对清单

1. 功能清单作为合同附件，逐条列明，且写明不包含项；
2. 付款分三期、每期卡一个签字确认节点，拒绝一次性全款；
3. 验收标准可执行：功能对照 + 缺陷分级 + 维护期起算日；
4. 源码、数据库结构、部署文档、账号的归属和交付时间写明；
5. 延期责任：因服务商原因延期怎么补偿，写具体，不写「友好协商」。

五条都在，这份合同可以签；缺任何一条，先补上再谈付款。