渐进式 Web 应用开发，是英国买家在项目开始的头十分钟里排除掉、又在十八个月后重新发现的方案，那时第二套原生代码库已经悄悄吃光了预算。它之所以被排除，是因为关于它的文字几乎都落在两个阵营里：跳过 iOS 拒绝做的那部分的鼓吹，或者继承自 2019 年、当时平台确实做不到的怀疑。 两者现在都错了，而且错在会改变成本账的地方。自 iOS 16.4 起，Safari 已支持添加到主屏幕的 Web 应用发送推送通知。Chrome 取消了安装对 Service Worker 的要求。英国监管机构在 2025 年 10 月认定苹果和谷歌在移动浏览器与浏览器引擎上具有战略市场地位。与此同时，iOS 仍然拒绝后台执行，会按你无法控制的规则清除已存...
小型企业
面向小型企业的实用网站和软件指南：无需过度支出即可在线发展的网站、切实可行的预算、工具和策略。
你能找到的几乎每一篇 Salesforce 与 HubSpot 的对比，都是由其中一方的合作伙伴写的。这不是阴谋，而是经济事实：能把这两款产品了解到足以比较的人，都靠实施其中一款谋生。结果就形成了一种文体，给一款产品最有力的辩护，给另一款一份礼貌的缺点摘要。 我们同时实施并集成这两款产品，也曾把客户往两个方向都迁移过。下面是我们隔着桌子回答客户提问时会给出的对比，价格是 2026 年 9 月从各厂商自己的定价页读来的，平台限额是从各厂商自己的文档里读出来的，而不是凭记忆写的。 简短的结论是：每篇对比都放在最前面的许可价格，是这个决定里最小的一个数字。真正决定结果的两个数字，是这套系统每个月需要多少管理投入，以及第三年你改变主意时要付...
搜索 wordpress vs wix，第一页几乎每一条结果都在给某个人付佣金。Wix、Squarespace 和大型托管式 WordPress 主机商全都在运营联盟计划，比较类网站的存在就是为了收割这些佣金，推荐结论在任何研究开始之前就已经由分成表决定了。这就是为什么那些结论听起来都一个调子，也是为什么它们回答的是一个没有哪家企业真正提出过的问题。 企业真正的问题不是哪个平台最好。这三个都足以支撑一个 15 页的宣传型网站，其中两个还会比一套疏于管理的 WordPress 做得更快、更可靠。真正的问题是这个网站三年后必须做到什么，以及无论你选中哪一个，离开它要付出多少代价。 写这篇文章的是一家靠把网站从这三个平台上迁走赚钱的公司，...
WordPress 主机的售价从每月大约 3 英镑一直排到几百英镑，而价格带两端的方案，用来描述自己的措辞几乎一模一样。快。安全。有备份。有支持。真正能让买家分辨它们的规格，也就是网站跑在哪个 PHP 分支上、背后是哪种数据库引擎、一共有几层缓存、其中又有几层真的开着，通常并不出现在你被要求下单的那个页面上。 这种缺失本身就是产品的一部分。“托管”是一个营销分类而不是技术分类，没有任何标准组织为它下过定义。两家都用这个词的服务商，可能在是否运行持久化对象缓存、是否允许你保留自己的缓存插件、备份能否离开他们的基础设施、你究竟能不能打开一个 shell 这些问题上完全不同。 下面写的正是那些页面略去的规格：WordPress 到底要求什...
大多数在找 Drupal 技术支持的人，手里已经有那个站点了。它可能是从一家早已转身离开的代理商手上接过来的，也可能是从一位离职的开发者那里继承下来的，而现在更新已经逾期，某个表单不再发信，又或者一份安全公告落了下来，却没有人说得清它是否与自己有关。他们要的不是一张销售页面，而是一份范围文档：工作到底是什么，一份公平的合同该怎么写，以及它应该值多少钱。 这篇文章就是那份文档。它列出一个 Drupal 站点每个月真正需要的工作、决定一份维护合同是否值钱的运营事实，以及英国现实的价格区间。请把供应商的报价单摊在旁边一起读，因为真正有用的部分，是发现报价单没有回答哪些问题。 有两件事让 Drupal 不同于一般的网站维护。它的安全公告按公...
Elementor 与自定义主题之争，通常被当成品味问题来吵，偶尔还被当成部落身份来吵。它两者都不是。它是一个成本问题，而且形状可以预测：页面构建器把成本从建站阶段挪到了网站的运营周期里。这笔交易划不划算，取决于两个几乎没人摆到桌面上的数字，一是网站有多少页面，二是这些页面多久改动一次。 争论迟迟没有结论，是因为双方都在用轶事说话。有人说构建器慢，另一个人贴出一张绿色的 Lighthouse 分数，什么也没有定下来。性能确实是一项真实成本，但它只是一张更长账单上的一行，同一张账单上还有授权续费、插件堆栈、内容编辑吞吐量、无障碍整改，以及最后把内容重新取出来的价格。 Elementor 不是一个糟糕的工具。对一大类网站来说它就是正确答...
在固定价格合同和按工时计费之间做选择，通常被描述成一次关于风险的选择。这个说法本身没错，但紧接着就被处理错了，因为双方都默认风险会消失，而不是只从一方转到另一方身上。 风险不会消失。在固定价格的安排里，供应商承担估算出错的风险，并把这份风险提前算进报出的数字里。在按工时计费的安排里，承担风险的是客户。真正的问题从来不是哪一种方式能消除不确定性，而是哪一方更有条件去管理它，以及为转移风险付出的代价值不值得。 能预判哪种方式管用的检验： 你能不能把“完成”写下来，写到两个人对是否已经达到这个状态能给出一致判断的细致程度？如果能，固定价格是你可以用的选项，而且多半是合理的。如果写不出来，固定价格合同并不会消除模糊，它只是把将来每一次分歧从...
软件 RFP，也就是需求建议书，本来的作用是让不同的供应商变得可以互相比较。可现实中大多数文件恰好起了反作用：它们把解决方案写得足够细，细到把答案的空间捆死，却偏偏漏掉了任何人报价时都需要的那些信息。结果就是五份报价，彼此相差一个数量级，形式上每一份都回应了要求，但没有任何两份在测量同一件事。 常见的解释是供应商在打太极。偶尔确实如此。但更常见的情况是，文件要了一个从它自身内容里根本推不出来的数字，于是每家供应商都用各自不同的假设去填补空白。假设不同，价格自然不同，这里并不存在诚不诚实的问题。 判断你的 RFP 是否有效的检验方法： 两家不同的供应商读完之后，能不能得出实质上相同的范围？如果文件里只写了“用户管理”，没有说明有多少种...
软件维护成本，就是那个把一个成功项目在十八个月之后变成一场难堪谈话的数字。开发阶段有预算、有审批、也如期交付了。可上线之后会发生什么，被一句「支持服务」轻轻带过，然后配上一个有人凭感觉给出的金额，而那个金额几乎每一次都太小。 原因出在结构上，不是谁不上心。开发有一个可以定价的范围。维护没有范围，因为决定它的是还没有发生的事情：某个依赖库爆出漏洞，某个供应商改掉了自己的接口，某个用户碰上了当初谁都没想到的情形。 人人都在引用的经验法则是每年按开发成本的 15 到 20 个百分点计算，而它之所以危险，恰恰是因为它离正确答案不远。 它对的次数多到让人放心，错的时候又总是朝同一个方向错：它低估了缺陷集中冒出来的第一年，而在有合规义务或者外部...
MVP 软件开发出问题的地方是范围会议，不是开发过程本身。有人说出「最小可行产品」这几个字，大家点头认可，接着送来的功能清单里却写着用户账号、后台管理面板、计费、通知、仪表板，还有一个移动应用。那不是最小可行产品。那是一个完整的产品，而它花掉的时间会是你心里那个数字的三倍。 真正造成损害的词是「可行」。多数团队把它读成「好到可以卖给所有人」，可它的本意是「刚好够用来判断到底有没有人想要这个东西」。 最省钱的范围测试： 对每一项功能，问问自己会因为答案不同而做出什么不一样的事。如果一项功能改变不了任何决定，它就不属于 MVP。后台管理面板不会告诉你人们是否想要这个产品；它只会告诉你，等人们想要之后，这个产品会更好管理。把它放到第二步再...