长期伙伴关系
系统上线了，大家松一口气。三个月后有个小问题没人处理，六个月后想加一个功能但当初做的人联络不上，一年后有人建议「不然重做一个吧」。这段过程你可能已经经历过一次。
长期伙伴关系让技术成为持续演进的资产，而不是一个不断折旧的项目。
重做的成本不只是再付一次开发费。你会再经历一次需求访谈、再培训一次团队、再冒一次上线的风险，而且这一次你对做技术的人已经少了一点信任。更实际的损失是中间那段时间——系统在原地，生意在动，两者的差距每个月都在扩大。
根本原因是项目式交付的结构本身：交付即结束，所以没有人的利益跟系统的长期健康绑在一起。开发方在交付那天就完成了他的责任，之后每一次修改都是新的一笔生意——这个结构不需要谁心怀不轨，它自然就会导向「上线之后没人负责」。业务在变，系统不动，两年后差距大到只剩重做这条路。
工作是怎么进行的
有人固定在看
监控、备份、安全更新、性能。多数问题在变成事故之前是有征兆的，有人在看就来得及处理；没人在看，你会在客户告诉你的时候才知道。
问题有地方去
出事的时候你知道找谁、大概多久有回覆。这听起来基本，但它正是项目式交付之后最常缺的东西。
跟着业务一起改
开了新分店、加了新产品线、换了会计软件——系统跟着调整，而不是等到差距大到必须重做。持续的小改动，长期成本远低于一次大重建。
定期回头看方向
每隔一段时间一起看：哪些在用、哪些没人用、下一步值得做什么、哪些当初做的东西现在可以拿掉。也包括「这一段现在不需要我们了」。
业务会变成什么样
- 系统不会慢慢烂掉
- 更新有人做、问题有人修、备份真的能还原——最后这一条很多人以为有，出事时才发现没有。
- 改动是加一块，不是重来
- 因为一直有人熟悉这套系统，加东西不需要先花两週重新理解它。这是长期合作最实际的成本优势。
- 技术决策有人一起想
- 要不要换供应商、这个报价合不合理、这个新工具值不值得试——这类问题可以先问，不必自己扛。
- 费用可以预期
- 月费或年度合约，不是每次出事再报一次价。可预期的支出比便宜的支出更好排。
包含什么
- 维护与监控
- 托管与域名管理
- 技术支援
- 持续改进定期检视下一步该走哪里，以及什么现在还不该做
持续支持
这项服务本身就是持续性的：月费或年度合约，而不是一次性交付。
这一项单独报价
网站配套有公开起价，因为范围够清楚。这一项没有，因为范围差距太大——给一个中间值，对小项目是吓阻，对大项目是空头支票。会先做一次免费诊断把范围谈清楚，再报价。
看网站配套的公开起价，以及为什么这一项没有什么情况下现在还不该做这个
现在不该做的：为了追新技术而重做。改动应该由业务需要驱动，不是由技术流行度驱动。
常见问题
- 不是你们做的系统，也能接吗？
- 可以，但要先看。会先做一次健检：代码状况、有没有文档、依赖的东西还有没有人维护、有没有明显的安全问题。有些系统值得接手继续养，有些老实说建议你换掉——我们会给结论和理由，不会为了接生意先答应下来。
- 这跟保固有什么不一样？
- 保固是修坏掉的东西，范围限在原本的交付内容。长期伙伴关系包含修，但重点在另一件事：让系统跟着业务走。前者是把东西维持在原样，后者是让它继续有用。价格结构不同也是因为这个。
- 可以随时停吗？
- 可以，而且停掉之后东西还是你的：域名、托管、代码、资料。我们不用「你离不开」来留客户——一段需要靠锁定来维持的关系，本来也撑不了几年。
- 我们很小，需要长期维护吗？
- 如果你的网站只是一个不常改的公司简介，那基本的托管与更新可能就够了，不需要完整的伙伴关系，我们会这样建议。但只要系统里有客户资料、有交易、有登入，那就不是「要不要维护」的问题——安全更新不做，出事的代价不是修复费，是信任。