小程序接单三年，我总结的避坑指南

做独立开发第三年，接单渠道从最初的QQ群、猪八戒，慢慢转到老客户转介绍和垂直社区。踩过的坑不少，今天把一些真实的经验写下来，给准备靠小程序接单吃饭的朋友做个参考。

先想清楚：你卖的是代码还是交付

很多新手接单时习惯按“页面数量”报价，比如一个页面300块。这种算法看起来公平，实际执行起来问题很大。客户理解的“一个页面”和你理解的往往不是一回事——他要的是带表单校验、带数据联动、带异常提示的完整交互，而你脑子里想的是静态布局。

我的做法是改成按功能模块报价，并且在报价单里把每个模块的边界写死。比如“登录注册”这一项，明确写清包含手机号验证码登录、微信授权登录，不包含短信服务商接入费用、不包含账号体系迁移。这样后期扯皮的概率会低很多。

报价单越像合同，后面越省心。含糊的地方，最后都会变成免费加班。

需求确认阶段的三件必做事

• 画流程图而不是写文档。大部分小客户看不完三页需求文档，但能看懂一张流程图。用draw.io画一遍主流程，截图发过去让对方确认，比文字描述有效得多。
• 确认数据归属。小程序后台、云开发环境、域名、服务器、支付商户号，这些到底归谁？我现在的默认做法是全部用客户主体注册，我只拿开发者权限，交付时一并移交。这样既避免客户担心被绑架，也避免自己背锅。
• 收定金再动手。30%到50%的定金是行业惯例，不接受定金的客户，大概率后面也不会有好结果。这条没有例外。

技术选型：别为了炫技给自己挖坑

接单场景下，技术选型的核心原则是可维护、可交接，而不是先进。客户后面很可能找别人接手，你的代码得让下一个人看得懂。

我目前的常用组合是原生小程序加云开发。原因很实际：小项目不需要单独买服务器，云函数和云数据库按量计费，客户成本低，我也不用维护运维。对于需要后台管理的项目，再配一个简单的管理端，用云开发的自定义登录或者直接走云函数鉴权。

// 云函数里做一层简单的权限校验，避免前端直接操作数据库
const cloud = require('wx-server-sdk')
cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV })

exports.main = async (event, context) => {
  const { OPENID } = cloud.getWXContext()
  const db = cloud.database()

  // 查当前用户是否为管理员
  const res = await db.collection('admins')
    .where({ openid: OPENID })
    .count()

  if (res.total === 0) {
    return { code: 403, msg: '无权限' }
  }

  // 通过校验后再执行实际业务
  return { code: 0, data: await doSomething(event) }
}

这段代码不复杂，但能挡掉大部分越权问题。很多接单项目出事故，就是因为前端直接调数据库，权限完全裸奔。

交付环节：留一份“傻瓜文档”

交付时我会写一份操作说明，不用专业术语，就按客户的操作习惯写。比如“打开微信公众平台，点左侧菜单的‘开发’，再点‘开发设置’，把里面的AppID复制给我”。这类文档花不了半小时，但能省掉后面无数次微信语音。

另外，源码、数据库结构说明、第三方账号清单，打包成一个压缩包，交付时一次性给全。别留后手，行业圈子小，口碑比一单尾款值钱。

关于报价的一点实话

小程序接单的价格区间非常大，同样一个点餐小程序，有人报三千，有人报三万。差价主要不在代码量，而在需求梳理、沟通成本、售后周期。我的建议是：新手期可以适当低价换案例，但一定要在合同里写清售后范围和期限，比如“交付后30天内免费修复bug，新增需求另行报价”。

接单这件事，技术只占一半，另一半是预期管理。把丑话说在前面，把边界划清楚，剩下的才是写代码。