很多老板第一次找小程序商城开发公司，开口第一句就是"做一个多少钱"。这句话一问出去，主动权就交出去了——对方报三万你也信，报三十万你也信，因为你手里没有一把能丈量工作量的尺子。真正难的不是比价，而是把两家看起来都在做同一件事的公司，放到同一张桌子上按同一套口径拆开看。这篇东西就是讲怎么拆：从需求怎么落到纸面、报价单怎么横着比、演示环节怎么验真、合同里哪几条必须写死，一直到上线之后半年才会浮出水面的那些成本。本地（标题里提到的那座城市）做小程序商城开发的公司，从三五人的工作室到上百人的团队都有，报价能差出五倍，这里面绝大部分差距不是技术差距，是口径差距。不管你是自己盯项目的运营负责人，还是被老板推出来"找人做个商城"的行政，看完至少能少踩两个大坑：一个是花定制的钱拿到换皮模板，另一个是被年费锁死三年导不出数据。
1. 需求先落纸：把自己从"我想要个商城"逼到"我要这二十几个功能"
我见过太多项目死在第一步，不是技术不行，是需求描述太含糊。你跟五家公司说"我要一个类似主流电商平台那样的商城"，五家给你的报价从两万八到十八万，你根本没法判断谁在坑你——因为"类似"这两个字，在销售的耳朵里是可以无限缩小的。落纸这件事听起来枯燥，但它直接决定了后面所有环节的可比性，省不得。
1.1 先认清自己要做的是四种形态里的哪一种
小程序商城不是一个东西，它至少有四个档次，功能量和价格带差得非常远。下面这张表里的区间是本地市场这两年比较常见的报价范围，2026 年人力成本还会往上走一点，但量级不会变：
| 形态 | 典型功能 | 定制开发常见区间 | 适合谁 |
|---|---|---|---|
| 展示型 | 商品列表与详情、图文、在线咨询、门店导航、预约留资 | 2 万–4 万 | 门店引流、品牌展示、客单价高但成交在线的品类 |
| 标准交易型 | 商品 SKU 与规格、购物车、下单支付、订单管理、售后退款、优惠券、运费模板 | 5 万–12 万 | 大部分做零售、批发小单、同城配送的商家 |
| 会员与营销型 | 在标准型基础上加会员等级、积分、储值、分销、拼团、秒杀、多门店与店员端 | 8 万–20 万 | 有复购逻辑、有门店网络、有私域运营团队 |
| 深度定制型 | 对接 ERP / 门店收银 / 供应链、定制结算分账、定制营销中台、多端数据打通 | 15 万起，多数按人天结算 | 已有信息化基础的连锁或生产企业 |
选错形态的代价很大。用展示型的预算去做交易型，最后一定会卡在"支付和订单怎么没有"上；反过来，一个只卖十来款单品的小店去做会员积分分销体系，做出来也没人运营，纯属给后台增加负担。判断方法很简单：把你未来一年真实会发生的业务流程写下来，看它需要几个角色参与——只有买家一个角色，多半是展示型；有买家、客服、仓管三个角色，标准交易型跑不掉；再加店长、区域经理、财务对账，那就是会员多门店型。
1.2 一页纸需求表：三栏结构比二十页文档管用
不用写几十页的需求文档，一页纸就够，但必须分成三栏：必须有、可以没有、以后再说。这三栏的意义在于，它把"要不要"变成了"先后顺序"，让开发方知道哪些是核心链路、哪些是可以砍掉换预算的。我见过一个做食品的商家，把"必须有"写了四十七条，最后一算报价十四万，把"可以没有"里的二十条一删，直接降到七万八，功能上一点没影响生意。
写的时候有一个硬要求：用能验收的语言描述，不要用形容词。举个对比例子——
- 不合格写法："要有优惠券功能，玩法丰富一点。"（这句话没有边界，开发方做三种券也叫丰富，做十种也叫丰富）
- 合格写法："支持满减券、折扣券、兑换券三类；满减券可设门槛金额；折扣券与满减券不可叠加，兑换券可与任意券叠加；每单限用一张；有效期支持固定日期和领取后 N 天两种模式。"
后一种写法看着啰嗦，但它能让五家公司的报价直接对齐——因为大家算的是同一件事。这一步做完，你会发现报价差距会从五倍缩小到一点五倍以内，剩下的差距才是真正该比较的东西。
1.3 先定"谁来维护"，再定"找谁开发"
这条最容易被跳过，但它决定了你该找哪种类型的公司。如果公司里有能写简单 SQL、看得懂后台配置、愿意折腾的运营，那你要的是源码交付 + 文档齐全，哪怕贵一点也值；如果全公司没人碰技术，那你要的是省心，产品化程度高、后台傻瓜化、有客服热线的团队更合适，年费制反而更划算。
还有一个中间态：自己有运营但没技术，这种最常见。我的建议是找能提供"半托管"的团队——源码给你，服务器和日常运维他们管，出问题他们兜。这类合作在合同里要写清楚运维边界，比如"服务器故障 4 小时内响应，工作日 8 小时内恢复"，别只写"提供技术支持"这种空话，真出事的时候这句话等于没写。
需求这一步还有一个隐藏收益：当你拿着三栏需求表和二十条可验收描述去谈，对方的销售态度会立刻变。懂行的会开始跟你讨论细节，不懂行的会继续跟你聊"我们做过很多类似案例"。这个反应本身就是一次筛选。
2. 报价单横着看：把总价拆成能逐行比对的颗粒
绝大多数人被报价单坑，不是因为价格高，是因为两份报价单的结构不一样。A 公司报八万,包含服务器和一年维护；B 公司报六万,服务器你自己买、维护另算、改个按钮另收工时费。你把两张纸放在一起看,以为 B 便宜两万,实际算完 B 可能贵三万。所以拿到报价的第一件事不是比总数,是把结构拉平。
2.1 一次性开发费和年费,那条线画在哪
市面上主流是三种收费结构,各有各的适用场景,没有绝对优劣:
| 收费结构 | 具体形式 | 优点 | 风险点 |
|---|---|---|---|
| 订阅制（SaaS 模板） | 每年 3000–3 万,按版本和功能包浮动 | 前期投入小,上线快,平台规则变更商家不用管 | 数据在别人库里,功能只能在他们给的范围内选,涨价没商量 |
| 项目定制 + 年维护 | 开发费一次付,年维护按合同额的 10%–20% | 源码自有,功能可长 | 年维护到底含什么,不写清楚就是扯皮重灾区 |
| 定制 + 买断 | 开发费一次付,交付后不再收年费,按次计费 | 长期成本最低 | 出了问题没人管,平台规则一变就得重新找人 |
选订阅制的商家最容易忽略一件事：你租的是使用权,不是资产。生意做起来想加个"门店自提"功能,对方产品里没有,你就只能等排期或者加钱定制,主动权完全不在自己手里。选定制的商家则容易忽略另一件事：年维护费里必须明确写清"包含平台规则变更导致的适配"。小程序平台的规则一年改好几轮,接口字段、隐私协议、类目资质说变就变,如果合同里没写这一条,每次适配都是一笔新的开发费,一次几千到上万。
2.2 三类隐藏成本,签合同前必须问到
第一类是基础设施成本。云服务器、域名、SSL 证书、短信验证码、对象存储流量,这些加起来,一个日订单两百单左右的商城,每月大概几百到一千多。这里有个特别容易翻车的点：商品图片如果不压缩就往上传,对象存储的流量费可能比服务器本身还贵。我见过一个做家居的商家,三百多款商品每张图都是手机原图直出,一个月流量费冲到两千多,后来让开发方加了图片自动压缩和 CDN 缓存,直接降到三百块以内。这笔钱在报价单上永远不会出现,但它实打实存在。
第二类是第三方能力调用。物流轨迹查询、电子面单打印、地址定位与地图、虚拟号码保护,这些能力大部分按调用次数收费,量小的时候几块几十块感知不到,量起来之后是一笔稳定支出。做同城配送的尤其要注意,轨迹查询是每一单都要调的。
第三类是变更工时。这是扯皮最多的地方。合同里如果只写"包含三个月内免费修改",那"修改"的定义就成了战场——改文案算修改,改页面布局算修改,加一个字段可能就要动数据库。我的做法是在合同附件里加一张工时单价表,写清"界面文案调整不计费、单页面结构重排按 0.5 人天计、新增字段与逻辑按评估人天计",把模糊地带提前切成块。
2.3 让每家填同一张人天表,报价的水分自己会浮出来
这是我最推荐的一招,实操性极强。你自己做一张表,把商城拆成十五到二十个模块,让对方逐行填"是否包含、人天、单价、备注",最后算总人天和总价:
| 模块 | 是否包含 | 预估人天 | 备注 |
|---|---|---|---|
| 首页与装修（可视化配置） | |||
| 商品与 SKU 管理 | |||
| 购物车与下单 | |||
| 支付与回调 | |||
| 订单与售后 | |||
| 优惠券与营销 | |||
| 会员体系 | |||
| 后台数据统计 | |||
| 联调与提审 |
填完你会有两个发现。第一个是人天总数能反推合理性：一个标准交易型商城,靠谱的团队大概在 60 到 120 人天之间,拆开是前端 25–40、后端 30–55、UI 8–15、测试 8–15,再加 10% 左右的项目管理。如果某家报的总人天只有 25,那基本可以确定是拿现成系统改的,不是从零做；如果报到 200 人天,你要问清楚多出来的一百多天在做什么,是不是把通用能力重复计了一遍。
第二个发现是单价能看出团队层次。本地市场的人天单价大致在 800 到 2000 之间,低于 800 的多半是学生团队或者转包,高于 2000 的一般是带了产品经理和项目经理的全职能团队,值不值看你项目复杂度。但要注意,单价低不等于划算——一个 800 单价做 150 人天的项目,总价十二万,跟一个 1500 单价做 70 人天的项目总价十万五,后者往往交付质量更好,因为人天虚高的部分通常是"边做边想"的返工。
3. 现场验真：五个问题问出一家公司是自研还是转包
演示环节是最容易糊弄人的。PPT 上十来个案例截图,每个都长得像模像样,但你可能不知道,很多公司演示的是同一套系统换了五套配色,或者干脆演示的是别家的产品。真正能分辨的,不是看他们展示什么,而是问那些只有真正参与过项目的人才知道答案的问题。
3.1 五个当场就能问的问题
第一个：你们的技术栈是什么,最近一次大版本升级改了什么。这个问题问的是"有没有在维护"。真正做技术的团队会告诉你后台用的什么语言、前端什么框架、数据库版本,并且能说出具体某次升级踩了什么坑,比如"从旧版本升上来的时候,定时任务那块重写了"。答得含糊的,基本是把开发外包出去了。
第二个：后台是自研框架还是开源二次开发。开源二开本身不丢人,很多成熟系统拿来改是合理的成本选择,丢人的是隐瞒。你要问的是二开的边界在哪——哪些是原系统自带的、哪些是他们加的。这个问题的实际意义在于：如果是深度二开,以后原系统升级你很难跟；如果是浅层二开,升级路径还算清楚。答"我们全部自研"但拿不出框架文档的,反而要警惕。
第三个：部署在谁的账号下。这一条是红线中的红线。云服务器账号、小程序平台的主体账号、支付商户号,这三样必须全部在你公司名下,开发方只拿子账号或者协作者权限。我见过太多商家图省事,让开发方代注册、代实名,最后想换服务商的时候发现账号拿不回来,数据也导不出,只能硬着头皮续费。这不是技术问题,是所有权问题,从第一天就要卡死。
第四个：上线后出问题谁值班,响应时效写在哪里。问的是运维机制。答"随时找我"的不可靠,答"我们有工单系统,工作日两小时内响应,紧急故障半小时"的才像话。还要追问一句"夜里十二点支付回调失败谁看",这个场景很真实,大促当晚最容易出。
第五个：现在同时在做几个项目,我这个项目排几个人,是全职还是兼着。排期能力比技术能力更能决定交付时间。一个五人团队同时接八个项目,你的项目一定是断断续续做的,沟通成本翻倍,工期必然拖。诚实一点的团队会直接告诉你"下个月有两个项目在上线,你这个排在月中启动",这种反而可信。
3.2 交付物清单:尾款付之前必须拿到手的东西
合同里写"交付源码"四个字是不够的,什么叫源码?数据库结构算不算?部署脚本算不算?我建议直接列成清单写进合同附件:
| 交付物 | 说明 | 交付时点 |
|---|---|---|
| 前端与后端完整源码 | 含注释,可独立编译运行 | 尾款支付前 |
| 数据库结构脚本与初始数据 | 含索引与字段说明 | 尾款支付前 |
| 部署文档 | 从空白服务器到跑起来,逐步可复现 | 上线后一周内 |
| 接口文档 | 含第三方对接说明 | 上线后一周内 |
| 后台操作手册 | 面向运营,配截图 | 上线后一周内 |
| 全部账号与密钥清单 | 服务器、数据库、第三方服务、平台后台 | 上线当天 |
| 压测报告 | 含并发数与瓶颈说明 | 上线前 |
清单里最容易被忽略的是"部署文档"。没有它,你就算拿到源码也搬不走,换服务器都得回头求人。这份文档的价值在你不需要它的时候是零,在你需要它的时候是无价的。
3.3 演示环节的三处造假,一眼能看穿
第一处:演示数据太整齐。真实的商城数据是脏的——商品价格有 9.9 也有 1280,订单时间分布在一天各个时段,商品图尺寸不统一,用户名有长有短。如果你看到的演示环境里所有价格都是整数、所有订单时间都是整点、所有图片都是同一尺寸,那这套数据是写脚本批量生成的,说明他们没在真实业务里跑过。
第二处:只演示前台不演示后台。前台好看不代表后台能用。一定要让对方打开后台,现场做三件事:编辑一个已有商品的 SKU 和库存、导出一批订单、配置一个满减活动。这三件事是运营每天都要做的,如果操作路径超过五步,或者保存之后要刷新才生效,那这个后台运营是用不下去的,最后所有事情都会变成"找开发改"。
第三处:案例问细节。别提"能不能联系一下你们的客户",对方一定说"客户不方便"。换个问法,问业务的细节:"这个客户的商品 SKU 最多有多少个""他们大促当天订单峰值大概多少""后台列表在十万订单量级下打开要几秒"。真正参与过的技术能答上来大概数字,转包的人只能含糊过去。
4. 合同里的坑:付款节奏、验收口径、源码归属怎么写才不吃亏
谈得再好,落在纸上的才算数。我处理过几次纠纷,回头看,问题几乎全部集中在三个地方:钱怎么付、什么叫做完了、东西归谁。这三条写清楚,九成的扯皮可以避免。
4.1 付款节奏:3:3:3:1 是最稳的结构
常见的坑是"5:5"或者"签约付 60% 排期"。前一种把风险平摊到了每一步但缺少质保约束,后一种等于把主动权全交出去了。我推荐3:3:3:1:
- 签约付 30%,对应需求确认与原型产出;
- 原型与设计稿确认付 30%;
- 提审通过、上线试运行付 30%;
- 上线满一个月、无重大缺陷付 10% 作质保金。
这个结构的关键在最后那 10%。它不高,但足够让对方在上线后一个月内保持响应。如果对方坚持"最低 5:5",那就要在合同里补一条"上线验收不合格,乙方需在 15 日内整改,逾期按日千分之三计违约金",用条款把风险补回来。
还有一个小细节:不要接受"按进度百分比付款"的模糊写法。"开发完成 50%"这种表述没法验证,必须绑定具体里程碑——原型签字、设计稿签字、联调通过、提审通过、试运行满七天,每一个都有可验证的产出物。
4.2 验收口径:把"能用"变成可以打分的数字
"系统运行流畅""用户体验良好"这类验收标准,写了等于没写。我一般建议列成指标表,双方签字确认:
| 指标 | 口径 | 阈值 |
|---|---|---|
| 首屏加载 | 4G 网络、中端机型、冷启动 | 1.5 秒内 |
| 页面响应 | 接口 P95 耗时 | 800 毫秒内 |
| 下单成功率 | 连续 200 次模拟下单（含支付回调） | 99% 以上 |
| 库存一致性 | 单品库存 10 件,并发 50 人下单 | 不超卖 |
| 后台列表 | 十万条订单数据下打开第一页 | 2 秒内 |
| 弱网表现 | 3G 模拟,断网重连后购物车不丢 | 通过 |
这张表的作用不是刁难开发方,是给"做完了"一个共同语言。真出问题时,你不用跟人吵"我觉得很慢",直接把手机拿出来跑一遍。另外验收单上一定要写一句"验收范围以双方签字确认的需求文档 V1.2 为准",版本号必须写,不然改了七八轮之后谁也说不清最终版是哪一版。
4.3 源码、数据、账号:归属条款一条都不能少
这部分我列成清单,建议直接抄进合同:
- 著作权归属:开发完成后,源码及相关文档的著作权归甲方所有,乙方保留在不泄露甲方商业信息前提下的通用技术复用权。
- 源码交付时点:明确写"甲方支付第三期款项后 5 个工作日内交付全部源码",不要写"项目结束后"。
- 二次开发权:甲方有权自行或委托第三方对源码进行修改,乙方不得设置技术障碍。这一条很重要,有些团队会在代码里埋授权校验,你不写这条,换人接手都跑不起来。
- 账号与资质归属:服务器、域名、小程序主体、支付商户号、短信服务、地图服务,全部以甲方名义注册,乙方仅有运维权限;合同终止后乙方需在 3 个工作日内移交全部权限并删除本地副本。
- 数据导出:乙方需提供全量数据导出功能(订单、商品、会员、优惠券),格式为 CSV 与 JSON,且不额外收费。
- 保密与不竞争:可选条款——乙方在合作期内及终止后 12 个月内,不得为甲方同商圈同品类的直接竞争对手开发功能高度重合的商城系统。
最后三条是我认为价值最高的。它们平时用不上,但它们决定了三年后你是能自由选择,还是被人拿捏。
5. 上线后半年:平台规则、压测、续费,那些报价单上不写的成本
项目上线那天不是结束,是真正开始。前面所有环节做得再漂亮,如果上线之后没人管,半年内一定出问题。这一段讲的是三个最容易被低估的长期成本。
5.1 平台规则是会变的,适配成本得提前锁定
小程序平台的规则一年要改好几轮,涉及的方向很固定:类目资质要求、支付相关的资质与风控、用户隐私协议与信息收集清单、内容与商品审核规范、接口字段的增删。每一次变更,后台就得跟着改,改得慢了会影响提审和正常使用。
我的经验是,把这部分成本在合同里锁定成一句话:"因平台规则、接口变更导致的适配开发,在年维护范围内,不另行收费;重大功能重构(工作量超过 5 人天)双方另行协商。"这句话看着不起眼,但一年下来能省掉几次几千块的额外账单,更重要的是,它让开发方有动力主动盯着平台公告,而不是等你去催。
另外一个实际操作上的建议:让对方在后台留一个"规则变更记录"页面,每次适配改了什么、什么时候改的、影响哪些功能,记一笔。这个页面在出问题时排查特别有用,尤其是支付和订单相关的改动。
5.2 大促之前的压测,重点不在"能不能扛",在"会不会超卖"
很多人以为压测是测服务器扛不扛得住,其实对商城来说,最致命的不是慢,是库存和订单不一致。一百个人同时抢十件库存,系统慢一点用户能忍,超卖了十单商家就得挨个道歉赔偿。
这里有两个技术方案要提前定:库存扣减时机和回调幂等。库存扣减有"下单预扣"和"支付后扣"两种,预扣能防止超卖但会产生大量占用库存的无效订单(需要定时释放),支付后扣体验好但在高并发下容易超卖。标准做法是下单预扣 + 15 分钟未支付自动释放,配合数据库行锁或队列串行化。回调幂等则是防止支付平台重复通知导致重复发货,实现方式是给每笔订单的回调加唯一键去重。
压测怎么做才有效?我的做法是提前两周,在测试环境模拟 200 并发下单,重点看三个地方:数据库连接池有没有被打满、下单接口的 P99 耗时、以及压完之后库存和订单数对不对得上。压完一定要做一次数据核对,这个步骤很多人省掉了,结果大促当天才发现账对不上。
5.3 续费与迁移:第一年就该验证能不能"走人"
订阅制的商家,第三年最容易被动。原因很简单:数据在人家库里,功能依赖人家的系统,涨价你只能接受。所以我的建议是,合作第一年就要做一次"迁移演练"——不是真迁,是让对方导出一份全量数据给你,你自己打开看看完不完整。
具体验证三件事:商品数据导出后,SKU 与规格的对应关系还在不在;会员数据导出后,等级、积分、储值余额对不对得上;订单导出后,退款状态和金额明细全不全。这三样只要有一项导不全,你就被锁定了,以后所有议价都没有底气。
定制开发的商家,迁移成本主要在两块:源码能不能独立跑起来、域名和小程序主体的备案归属。前者靠部署文档验证,后者靠账号归属验证。这两样都在自己手里,迁移就是换个技术团队接手的事,成本可控;有一样不在,迁移就是重做。
我个人的体会是,选开发公司这件事,技术能力的重要性排在第三位,排第一的是所有权清晰,排第二的是沟通响应。技术再强的团队,如果账号不在你名下、源码不给你、出问题找不到人,那你买的不是系统,是一份长期的被动。反过来,一个技术中等但做事规矩的团队,配上清楚的需求和合同,做出一个能稳定跑三年的商城完全没问题。至于本地那么多家怎么挑,把前面那张人天表发出去,让愿意认真填的留下,剩下的自然就筛掉了。
