独立开发者的报价方式：为什么给区间，以及什么时候不该接

#背景

独立开发者最容易在两件事上吃亏：报价报低了，和范围没写清。

低价的根源往往不是"算错了工时"，而是把不确定的东西当成确定的——"顺便再加个后台"、"能不能也接个支付"、"上线后帮我改改"这类口头承诺，会在交付期变成几十小时的无偿劳动。

#做法：三种口径

#1. 官网/展示类：按页面与内容规模报价

这类项目工作量几乎全在「信息架构 + 内容整理 + 响应式细节」上，功能是标准件：

• 报价区间给出来（如 8,000 ~ 20,000），区间两端对应明确的规模差异；
• 合同里写清页面数量上限、内容由谁提供、改稿轮数（通常 2 轮）。

关键一句话："内容由甲方提供"。如果内容也要你写，那不是加钱的事，而是工期会翻倍。

#2. 系统类：先做需求拆解，再报价

不能凭感觉报价。把需求拆成三档：

报价单里把"必须"之外的部分逐项标价，客户自己就能决定砍哪些——比争论"太贵了"有效得多。

#3. 长期维护：按年/按次

上线不是终点：依赖升级、服务器续费、内容改动、突发排障都要时间。两种方式：

• 按次：适合改动少的站点，按工时计（写明最小计费单位，比如 0.5 小时）。
• 按年：适合持续迭代的系统，约定响应时限与月度额度，超出部分按次。

#需求变更怎么算

这是最该写进合同的一段：

变更若超出原需求文档描述的功能范围，双方确认工作量后按 ¥X/人日 计价，或置换等量的原范围功能。

把"加钱"变成默认流程而不是"翻脸时刻"。实践中，写好这条之后，绝大部分变更会因为"要加钱"而被客户自己砍掉——这本身就是收益。

#什么时候不该接

• 决策链不清晰：三个人都能提需求，且互不认可。你会发现"改稿"永远没有终点。
• 预算与目标不匹配：想要电商全链路、预算却是官网的量级。这时候要么明确砍需求，要么直接不接——接了必翻车。
• "先做着看，成了再给钱"：独立开发者的现金流撑不住这种赌注，除非你本来就把它当投资。

#结果

按这套口径谈，最明显的变化不是"报价变高"，而是扯皮变少：客户知道每加一项要多少钱，你也知道每个阶段交付什么。合同里能写清的东西，谈不成的关系也不值得勉强。

#取舍

• 不接超低价"练手单"：短期有收入，但会占住档期、压低你的价格锚点，长期是负收益。
• 不承诺"包上线包过审"：备案、ICP、第三方审核的通过与否不由你决定，能承诺的是"按你的要求完成技术实现并配合整改"。
• 报价差异化而不是统一价：同样的官网，品牌客户与个人客户的沟通成本差三倍，价格理应不同——报价是商业判断，不是数学题。