我的需求目前还不完整，可以先给一个大致报价吗？

结论：需求不完整时可以先给带假设的预算区间，但只能用于立项筛选；要签固定总价，必须先补齐首期范围、接口、数据、质量目标和验收标准。任何区间都应同时写明基准、上下界和最敏感的变量。

“大致报价”可以用于判断预算是否明显不足、基本匹配或值得继续梳理，但不能承诺最终金额。我们会同时给出范围假设、主要未知项、估算区间和下一步需要确认的资料；信息越少，区间就越宽。

在形成预算、报价范围与成本假设时，还可以对照 定制软件项目一般怎么收费？ 和 项目做到一半预算紧张，能不能先上核心、分期推进？；这些内容补充了需要放在同一项决策中考虑的上下文。

三个阶段的数字不能混用

估算阶段	已有证据	输出形式	适合决策	不能用于
数量级粗估	业务目标、主要用户、渠道和少量约束	宽区间 + 关键假设 + 排除项	是否继续调研、采购还是自建	签固定总价或承诺上线日
预算估算	主流程、原型、端、接口清单、数据样本	工作包区间 + 外部费用 + 风险情景	内部立项和预算审批	把未验证接口视为固定成本
合同报价	范围基线、验收、责任、真实接口和质量目标	费率/总价、里程碑、变更和付款	正式采购与交付	覆盖合同外未来蓝图

粗估也不是随口报数。至少要形成一页估算基准：解决哪个问题；谁完成什么任务；首期包含哪些端和角色；是否新建后台；有哪些支付、地图、AI、硬件或旧系统接口；要迁移什么数据；预计业务量、地区与上线责任；明确不包含哪些事项。每个未知项标成假设，并写出如果假设不成立，成本向哪个方向变化。

先找出最能改变价格的五类变量

变量	低复杂度假设	高复杂度可能性	如何尽快验证
业务状态	单向提交和查询	并发库存、退款、分账、审批与审计	画状态图和异常案例
外部接口	有沙箱、文档和负责人	无文档旧系统、多方联调、硬件协议不稳	真实凭据跑一个技术样例
数据	新系统或整洁小样本	多年脏数据、主键冲突、不可停机迁移	数据画像和试迁移
渠道与设备	单一 Web/小程序	iOS、Android、多小程序、离线或硬件	列关键能力并真机验证
质量责任	一般工作时段服务	高并发、跨区容灾、7×24、严格合规	写 SLO、RTO/RPO 和监管清单

例如可以写成：“在仅做微信小程序与后台、无历史迁移、两个接口均有沙箱、工作日支持的基准下为 A—B；若需要原生双端、接口需反向梳理或迁移历史订单，则分别增加对应工作包并重估。”A、B 必须来自团队当前费率和人天，而不能从另一客户案例复制。

花钱澄清最贵的未知项，而不是先写完整文档

如果区间太宽，优先验证最可能改变决策的事项：旧系统能否对接、硬件协议是否稳定、关键用户是否会完成流程、数据是否可迁、平台类目是否允许。一个可运行样例或数据试迁移，常比几十页功能列表更能收窄预算。发现阶段的交付应包括证据、失败结论和更新后的区间，即使最终不开发也有价值。

滚水科技会提供注明日期和假设的初步区间，并标出客户可以自行补充的材料；若需要原型、接口验证、数据分析和可供多家比价的工作分解，则作为独立发现服务约定成果。我们不会承诺所有前期深度设计永久免费，也不会把咨询费藏进后续开发总价。