小程序定制：别急着写代码

做小程序定制这几年，我见过太多项目死在第一周：需求还没聊清楚，合同已经签了，代码已经开工了。三个月后双方扯皮，甲方觉得被坑，乙方觉得甲方需求天天变。问题不在技术，在于定制的起点搞错了。

先分清：你需要的到底是定制还是配置

很多客户开口就是「我要定制」，但聊十分钟就发现，他的需求用现成模板+SaaS 后台就能覆盖八成。定制意味着从零写业务逻辑、自己维护服务器、自己处理迭代，成本是模板的几倍到几十倍。判断标准很简单：

• 业务模式是否与市面上成熟产品高度重合？重合就别定制。
• 核心壁垒是否在软件本身（算法、独特流程、数据资产）？在，才值得定制。
• 是否有长期迭代预算？定制是一次性交付、长期维护的买卖，没有维护预算的定制项目，上线即巅峰。

一句实话：多数「定制需求」本质是「我不满意现有产品的交互细节」，这属于二次开发或换供应商，不属于定制。

需求文档不是功能清单

我收到过最典型的需求文档，是一张 Excel：功能名、优先级、备注。这种文档做不了定制，因为它只写了「做什么」，没写「怎么算做完」。一份能落地的需求，至少要有三样东西：

• 角色与流程：谁在用，从哪进，走到哪结束。用文字把主流程串一遍，比画十张原型图有用。
• 边界条件：支付失败怎么办、库存为 0 怎么办、审核不通过怎么办。这些才是开发工时的大头。
• 验收口径：每个功能怎么算通过，最好能写成可执行的检查项。

我习惯在报价前先做一轮「需求对焦」，把模糊词全部翻译成具体行为。比如「要好看」翻译成「首页三屏内完成主转化路径」，「要快」翻译成「首屏渲染 1.5 秒内」。这一步花两天，能省后面两周的返工。

报价差异为什么能差三倍

同样一个带支付的小程序，有人报两万，有人报八万。差价通常不在写代码，而在这几处：

• 是否含后台：只做小程序端和连管理后台，是两个量级的活。
• 是否含设计：套组件库和从零做视觉稿，成本差得很远。
• 是否含上线与资质：类目选择、支付开通、隐私协议、备案，这些琐事很吃时间。
• 是否含源码与部署：交付源码、交付部署文档、交付服务器，是三档不同的承诺。

报价单里最该盯的不是总价，是交付物清单。没有清单的报价，等于没报价。

外包避坑的三条硬规则

• 分期付款绑定里程碑：需求确认、原型验收、核心流程跑通、上线，四个节点对应四笔款，别一次性付大头。
• 代码托管在你自己名下：从第一天起，仓库、云账号、小程序主体都归甲方，乙方只拿协作者权限。这条能过滤掉八成不靠谱的团队。
• 写清变更机制：需求变更怎么算工时、怎么计价，提前约定。没有变更条款的合同，最后一定变成拉锯战。

一个真实项目的节奏参考

去年做一个带预约和会员储值的小程序，团队两人，周期六周。节奏大致是：

第 1 周：需求对焦 + 流程梳理 + 报价确认
第 2 周：原型与视觉稿，甲方逐页签字
第 3-4 周：核心流程开发（登录、预约、支付、核销）
第 5 周：后台管理 + 联调 + 真机测试
第 6 周：提审、修问题、上线、交付文档

注意第 2 周的「逐页签字」。这一步看着繁琐，但它把后面所有的争议挡在了开发之前。项目能按时上线，靠的不是开发快，是前面把不确定的东西都确认掉了。

上线不是终点

小程序上线后还有一堆事：版本迭代、接口维护、微信规则变化、性能优化。定制项目真正的成本曲线是「前期高、后期持续」，签合同前就要想清楚谁来接这个盘。我的建议是，在合同里单独约定上线后三个月的免费修复期，以及之后的维护单价，把长期关系写明白，比什么都实在。

小程序定制的核心不是技术选型，是把模糊的需求变成可验收的交付。想清楚这一点，再动手写第一行代码。