门店小程序开发，我踩过的那些坑

去年帮一个开连锁烘焙店的朋友做门店小程序，前后折腾了三个月。不是技术多难，是坑太多。今天把过程里那些真金白银换来的经验写下来，给准备做门店小程序的同行和老板们提个醒。

先想清楚：门店小程序到底解决什么问题

很多老板一上来就说“我要个小程序”，问他要干嘛，答“别人都有”。这种需求我一般直接劝退。门店小程序开发的核心价值就三件事：

• 把到店流量沉淀下来——扫码点单、会员积分，让顾客下次还来
• 降低人力成本——排队、点单、核销这些重复动作交给小程序
• 做私域——把用户留在自己的池子里，而不是全给平台交佣金

如果这三条你一条都不沾，那真没必要做。我见过太多花两万块做了个小程序，最后沦为“电子菜单”的案例。

技术选型：别被“定制开发”四个字忽悠

门店类小程序，90% 的功能是标准化的：商品展示、下单支付、订单管理、会员卡、优惠券。这类需求我现在的做法是：

• 能用 SaaS 模板解决的，绝不写代码。一年几千块，比开发便宜十倍
• 确实需要差异化的（比如烘焙店的“预约自提+生日提醒”），再考虑小程序定制开发
• 后端优先考虑云开发，省掉服务器运维，小门店根本用不上独立服务器

说个真实数据：一个基础门店小程序，用云开发 + 原生小程序，我一个人两周能出可用版本。但如果客户非要“从零定制”，光需求评审就能拖一个月。

几个容易翻车的技术细节

1. 支付资质别到最后才办

微信支付商户号申请、类目审核，快则三天慢则两周。我第一个项目就是代码写完了卡在支付上，客户天天催。现在我的流程是：签合同第一件事就是让客户去办营业执照和商户号。

2. 门店多的时候，库存和订单要分店隔离

连锁店最容易出问题的就是库存。A 店卖完了 B 店还在显示有货，顾客到店发现没有，体验直接崩。数据结构上一定要留 store_id，订单、库存、会员卡都按门店维度隔离，别图省事做成全局的。

// 订单表关键字段设计
{
  orderId: 'xxx',
  storeId: 'store_001',   // 门店隔离的核心
  userId: 'openid_xxx',
  items: [...],
  status: 'paid',
  createdAt: Date.now()
}

3. 扫码点单的桌号/取餐号要防并发

高峰期几十个人同时下单，取餐号如果用小程序的本地自增，必然重复。老老实实用云函数里的事务或者数据库自增，别耍小聪明。

关于费用，说点实在的

经常有人问我门店小程序开发多少钱。我的回答永远是：看你要什么。简单列个参考（一线城市独立开发者报价）：

• 模板/SaaS 方案：3000~8000 元/年
• 半定制（标准功能+少量定制）：1.5 万~3 万
• 全定制（含多门店、复杂会员体系）：5 万起，上不封顶

低于这个价太多的，要么是模板套壳，要么后期维护找不到人。外包避坑的第一条就是：别只看报价，看对方能不能说清楚你的业务逻辑。

上线之后才是真正的开始

小程序上线只是起点。我朋友那家烘焙店，上线第一个月日订单不到 10 单，后来做了三件事才慢慢起来：

1. 店内每张桌子贴点单码，服务员主动引导
2. 首单立减 5 元，把线下客流往线上导
3. 每周三会员日，用小程序推送召回

三个月后日订单稳定在 80 单左右，人力省了一个收银员。这才是门店小程序开发该有的样子——不是做个摆设，是真的在帮门店赚钱。

最后一句忠告：找开发者聊的时候，多问“我这个店的具体场景你怎么处理”，少问“能不能便宜点”。能把你业务讲明白的人，代码一般不会差。