一个点餐小程序，我是怎么把成本压到八千的

后台经常有人问我：做一个点餐小程序到底要多少钱？网上报价从三千到三万都有，看得人心里没底。与其空谈报价，不如把我去年接的一个真实案例拆开讲讲——一家开在写字楼底商的快餐店，堂食+外带，没有配送，最后交付价八千出头。钱花在哪、省在哪，看完你自己就能算账。

需求先砍一半，报价自然降下来

老板一开始的设想很丰满：会员积分、储值卡、拼单、优惠券、后厨打印、外卖对接。我让他先回答一个问题：现在店里一天多少单？答案是一百二十单左右，高峰期两个服务员已经忙得过来。

那结论就很清楚了：先把“提升效率”的需求砍掉，只保留“减少出错”和“沉淀老客”的部分。最后定下来的功能只有四块：

• 扫码点餐，桌号用二维码带参数区分
• 菜单管理，老板自己在后台改价格和上下架
• 微信支付，付完直接出小票
• 简单的会员余额，充多少送多少由老板自己配

储值卡、拼单、外卖对接全部砍掉。很多小店的真实痛点不是功能不够，而是功能太多没人用。砍需求这件事，省下的不只是开发费，还有后期的维护心智。

技术选型：云开发把后端成本抹平了

这种体量的项目，我基本不碰自建服务器。原因很现实：小店老板不懂运维，我也不想半夜接电话处理证书过期。

用微信云开发，数据库、云函数、存储、静态托管一套带走。订单写入用云函数，避免客户端直接操作数据库；菜单图片走云存储；支付回调也放在云函数里处理。真正需要自己写的“后端代码”大概三百行。

// 云函数：创建订单（节选）
const cloud = require('wx-server-sdk')
cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV })
const db = cloud.database()

exports.main = async (event, context) => {
  const { OPENID } = cloud.getWXContext()
  const { tableId, items, total } = event

  if (!items || !items.length) {
    return { code: 400, msg: '购物车为空' }
  }

  // 金额以分为单位，服务端重新计算，不信任前端
  const realTotal = items.reduce((s, i) => s + i.price * i.count, 0)
  if (realTotal !== total) {
    return { code: 400, msg: '金额校验失败' }
  }

  const res = await db.collection('orders').add({
    data: {
      openid: OPENID,
      tableId,
      items,
      total: realTotal,
      status: 'unpaid',
      createTime: db.serverDate()
    }
  })
  return { code: 0, orderId: res._id }
}

这段代码里最重要的不是语法，而是那句“不信任前端”。金额必须在服务端重算，否则改个请求参数就能一块钱吃一顿饭。这类坑我见过不止一次。

真正耗时间的不是写代码

按工时算，编码大概占了四成，剩下六成全是这些事：

1. 菜单录入。老板给的菜单是手写拍照，一百多个 SKU，规格、加料、图片全靠人工整理。这块我让他自己用表格填，我只做导入模板，省了两天。
2. 支付资质。个体户营业执照、对公账户、类目选择，来回补了三次材料，前后一周多。这个时间一定要提前跟客户说清楚，不然他会以为你在拖。
3. 打印机联调。小票机走的是局域网云打印，桌号和取餐号对不上，调了半天才发现是模板变量拼错了。
4. 现场试跑。开业前一天在店里蹲了三小时，看服务员怎么用，改了两处按钮位置。这半天比写一周代码都值。

成本拆解，摊开说

• 小程序认证：300 元/年（客户自己出）
• 云开发：前期用基础套餐，每月几十块，量小基本够用
• 云打印小票机：四百多一台，客户自购
• 开发费用：八千，含设计、开发、上线、一个月内小改

这里没有算我自己的时间成本。如果按人天报价，这个项目大概十五个工作日，折算下来单价并不高。之所以能做，是因为需求足够窄、技术栈足够熟、沟通链路足够短——老板就是决策人，不用层层汇报。

几个事后才想明白的点

第一，后台一定要做给老板自己用。改价、下架、看订单，这些必须他本人能操作，否则你就是在给自己挖售后坑。

第二，别急着上会员体系。这家店上线三个月后，储值用户还不到五十个。小店的复购靠的是口味和位置，小程序只是把点单这一步变顺了。

第三，留好数据出口。订单表结构尽量扁平，字段命名别图省事。后面老板想接第三方收银系统，导出 CSV 就能用，不用再改一遍代码。

案例讲完了，说句实在话：报价高低本身说明不了什么，关键是需求边界有没有划清楚。同样叫“点餐小程序”，带不带配送、要不要对接供应链，成本能差出好几倍。先想清楚自己到底要解决什么问题，再去谈价格，比什么都强。