北京小程序定制开发，我踩过的那些坑

上周跟一个北京的老客户吃饭，他问我：你们做小程序定制开发这么多年，北京这边客户最难搞的需求是什么？我想了想说，不是预算，也不是工期，是“我以为”。

客户以为小程序就是做个页面；以为上线就能爆；以为改个按钮不要钱。做了七年小程序开发，我越来越觉得，技术问题都好解决，难的是把“我以为”翻译成需求文档。

北京客户的特点：要求高，但信息差也大

北京市场有个很分裂的现象。一方面，大厂出来的产品经理遍地都是，需求文档写得比我们开发还细；另一方面，传统行业老板也很多，开口就是“我要一个像美团那样的”。

去年接了个做企业服务的单子，老板是河北人，在北京做B端生意十几年。需求聊了三次，每次他都说“很简单，就是让客户能在线下单”。结果第一版原型出来，他加了四十多条意见，从权限体系到发票管理，全冒出来了。

这不是客户故意藏着，是他自己一开始也没想清楚。所以我现在接北京的小程序定制开发项目，前期一定会做一件事：陪着客户把业务流程走一遍。不是问他要什么功能，而是看他平时怎么干活。很多需求藏在他每天的操作习惯里，问是问不出来的。

定制开发和模板，到底怎么选

经常有人问我，北京做小程序开发，是找模板还是定制？我的回答一般很直接：

• 业务流程标准、预算有限：模板或SaaS够用，别硬上定制，钱花了效果未必好
• 有独特业务逻辑、要对接内部系统：老老实实定制，模板改到最后比定制还贵
• 只是先试水：用最低成本跑通闭环，跑通了再迭代，别一上来就all in

我见过太多反例。有个做餐饮连锁的客户，一开始图便宜买了套模板，结果会员体系和他们的储值卡规则对不上，硬改代码改了两个月，最后推倒重做。这笔账算下来，比一开始就定制贵了将近一倍。

定制开发贵的不是代码，是前期把需求想清楚的那段时间。想清楚了，后面反而省钱。

一个真实的技术取舍

说点技术上的。北京这边很多客户要求小程序和APP数据互通，这时候架构选型就很关键。我一般建议小程序端走云开发或者轻量后端，APP端单独一套，中间用统一的API网关做数据层。

举个例子，用户状态同步这块，最省事的做法是共用一套用户中心：

// 统一用户标识，小程序和APP共用
const userId = await getUserCenterId(openid, platform);

// 业务数据按平台打标，但主数据只有一份
await db.collection('orders').add({
  userId,
  platform: 'miniprogram',
  status: 'pending',
  createdAt: Date.now()
});

这样后面无论加H5还是加抖音小程序，用户体系不用重做。很多团队一开始图快，每个端各写一套，后期数据对不上，扯皮能扯半年。

关于报价，说点实在的

北京小程序开发费用跨度很大，从两三万到几十万都有。我的经验是，报价低于市场均价太多的，基本都有坑：要么是套模板改个皮，要么后期疯狂加钱，要么做完就跑路。

判断一个团队靠不靠谱，我一般看三点：

1. 愿不愿意在签合同前帮你梳理需求，而不是急着报价
2. 能不能说清楚哪些功能是标准件、哪些要单独开发
3. 上线后有没有维护期，出问题找谁

这三点比看案例、看公司规模都管用。我见过办公室在国贸、案例做得漂亮，但交付完就失联的团队，也见过两三个人的小工作室，活干得踏踏实实。

最后一句

小程序开发这个行业，技术门槛在降低，但把需求翻译成产品的能力反而更值钱了。北京市场尤其如此，客户不缺想法，缺的是能帮他把想法落地、还愿意说“这个功能其实没必要做”的人。

如果你正在找北京的小程序定制开发，我的建议是：多聊几家，重点看对方问的问题，而不是看对方给的价格。问得越细的，大概率越靠谱。