先说结论：合同里最该钉死的是"什么时候给钱"和"什么样算合格"

我们讲过开发合同怎么写、也讲过合同主体与发票，但合同里最容易被轻描淡写、出事却最要命的两块，是付款节点和验收标准。钱怎么分阶段给、做到什么程度算交付，这两件事写不清，后期要么被卡进度，要么被拖着不给尾款。这篇把这两块拆透。

一份小程序开发合同，付款通常分哪几个节点？

主流做法是把总价拆成几笔，按里程碑释放，而不是一次性付清或按月均摊，典型的分法长这样：

  • 定金（签约后）：占小头，锁定排期和资源，一般 10% 到 30%；
  • 原型确认后：UI 和交互定稿、你签字确认，再放一笔，约 20% 到 30%；
  • 开发完成 / 测试通过后：核心功能跑通、内部测试没问题，放主要部分，约 30% 到 40%；
  • 正式上线后：通过微信审核、正式发布，放接近尾款的一笔；
  • 质保期结束后：留 5% 到 10% 作为质保金，运维过保再付——这和我们讲售后运维、讲故障应急时"留尾巴保质量"是同一个思路。

关键原则：最后一笔一定要在上线且你验收通过后才给，别在开发中途就把钱给光。

验收标准怎么写，才不会"做完不算完"？

最危险的合同写法是"开发完成后付款"，因为"完成"没有客观标准，对方说完成你就得给钱。验收标准要落到可核对的具体项，建议至少写清三层：

  • 功能清单对照：合同附件列出每一项功能，逐条演示通过才算，这和我们讲功能 UAT、讲需求文档时的"逐条对齐"一致；
  • 性能指标：页面打开速度、并发承载、关键流程成功率，给具体数值而不是"流畅运行"这种空话；
  • 缺陷容忍度：上线后严重 bug 数量上限、修复时限，写清超标的处理方式。

把"什么样算合格"写成数字和清单，对方才没有模糊空间。

合同里还该写清哪些和钱有关的条款？

付款和验收之外，还有几条文不直接写钱、却直接影响你最终花多少，签之前务必有一条：

  • 需求变更的计价规则：超范围功能怎么算钱、响应时效怎么约定，避免"随便改一点就加一笔"——这接上我们讲变更管理时的范围基线；
  • 延期与违约条款：对方延期交付的违约责任、你侧素材不到位的免责，双方对等；
  • 源码与账号交付：上线同时必须交付源码、后台账号、商户号等全部资产，和我们讲源码归属、讲账号资产时强调的"资产归你"对应；
  • 知识产权与发票：著作权归属、开票类型与时间，这部分在我们讲合同主体与发票时单独展开过。

条款写得细，不是不近人情，是给双方都省去日后的口舌。如果你手上的合同草稿拿不准，发我们帮你看，方案评估免费——我们重点帮你查付款节点和验收标准这两块。

签完合同、付了定金，还要注意什么？

合同签了不等于高枕无忧，执行阶段有几件事盯紧了，能避免绝大多数纠纷：

  • 每个节点都要书面确认：原型确认、测试通过、上线发布，每一步留邮件或聊天记录，别只口头"行了吧"；
  • 款项对应节点释放：对方没到里程碑就催款，按合同回绝，别被"快过年了急用"这类话术带偏；
  • 保留质保金话语权：尾款和质保金是你的最后筹码，对方售后缩水就拿这笔说事。

合同是合作的底线，不是起点也不是终点。如果你正准备签开发合同、不确定条款是否站得住，把草稿发我们，方案评估免费——我们帮你把风险点一条条标出来。