多端重构的账单，很少直接写在报价单上。多数团队是在单端跑通之后才决定增加商家端和管理后台，评估时往往停留在“再做两套界面”，而真正的支出，来自已经被单端假设固定下来的数据结构和接口层。
增加端，不只是增加界面
后端接口要重新设计，数据要打通，测试要覆盖多端兼容。原来用户下单是一条线性链路，接上商家端之后，订单状态机要扩展成接单、服务完成、用户确认、平台结算的完整流程，数据表要重新设计，接口要重新定义。按经验值，商家端增加的工作量大约相当于用户端的六到八成，三端齐全的项目总工作量约为单端的 2.5 到 3 倍，这还没算多端联调、多端测试和多端发版的重复开销。
真正昂贵的是结构性返工
后端的数据结构和接口如果只按单端思路做，后期加端时改动成本会很高，严重的甚至要推倒重来。权限体系、结算对账、入驻审核这些属于平台侧的能力，在单端阶段通常没有被设计进去。等到需要加端时才会发现，它们只会涉及既有表结构和接口的改动，无法靠简单新增模块解决；因此，这类改动的范围通常会扩散到已有的业务链路中。
交付物的账，会在重构时结算
源码、文档、部署脚本、测试报告，前期省掉的每一项都会在重构时变成成本。没有文档，接手的人要重新读代码；没有源码，迭代必须回到原服务商。行业经验中，上线后的运维支出通常占首年总预算的百分之十五到二十五，交付物不完整会让这个比例更高。
判断一次多端重构是否划算，不能只比“加端报价”和“重做报价”。先把角色划分、状态流转、权限边界和交付要求列成清单，再让服务商按结构复杂度而不是界面数量给出工作量依据。先用单端验证业务模式是合理的，但数据结构一旦只按单端设计，省下的前期投入往往会在加端时成倍还回来。
