一份定制开发报价单上，“源码交付”往往只占一行字，却是整份合同里权属边界最明确的一处。不少需求方在比价阶段只盯着总价，等到系统上线后想增加一个流程、换一家服务商接手时，才发现自己买到的不是一套可以自行处置的软件资产，而是一项受制于人的使用许可。低价与高价之间最实质的差额，常常就落在这里。
源码交付改变的是产权性质
定制开发的对价本来应当包含两样东西：一套可运行的系统，以及生成这套系统的工程文件，包括接口、数据库结构、管理后台和各端前端代码。只交付前者时，所有权在事实上仍停留在服务商一侧；需求方获得的是一次性使用资格，而不是可持续演进的资产。
这种安排在初期并不容易察觉。系统平稳运行时，交付与不交付源码看起来差别不大。一旦业务发生变化，差异立刻放大：任何调整都只能回到原厂，报价缺乏横向比较基准；若合作中断或原厂转向其他方向，新团队拿不到工程文件，等于从零重构，前期投入沉没。
议价权随代码一起转移
源码决定的是后续维护市场的竞争结构。持有源码，需求方可以在多家服务商之间询价，以工程文件本身作为谈判依据；不持有源码，维护市场就退化为单一供应商，价格由对方的定价能力而非市场行情决定。所谓“上线后被加价”，根源多数不在服务态度，而在这种结构性垄断。
因此判断报价是否合理，不能只看总价，而要把交付范围摊开逐项核对：是否包含完整源码、何时交付、交付到何种程度。可编译、可独立部署的工程文件与打包后的运行程序，是两类完全不同的交付物，只有前者支撑后续自主迭代。
合同里要写清楚的三件事
一是交付范围，明确后端接口、数据库脚本、管理后台、各端前端是否完整移交；二是交付时点，与验收款绑定，而非无限期搁置；三是权属条款，写明著作权归属及第三方组件授权边界——定制部分归需求方，通用开源组件依其原许可使用，两者分开约定。
也要承认例外：模板与轻定制本身就以“不交源码、价格低、扩展性差”作为交换条件，需求简单、功能固定时属于合理取舍。问题不在于便宜，而在于用定制的价格买到模板的交付方式。判断标准始终是同一条：报价与交付范围是否匹配。低价单上“源码交付”一栏的空缺，通常就是差价真正的来源。
