漸進式網頁應用程式開發，是英國買方在專案開始的頭十分鐘裡排除掉、又在十八個月後重新發現的方案，那時第二套原生程式碼庫已經悄悄吃光了預算。它之所以被排除，是因為關於它的文章幾乎都落在兩個陣營裡：跳過 iOS 拒絕做的那一部分的鼓吹，或者承襲自 2019 年、當時平台確實做不到的懷疑。 兩者現在都錯了，而且錯在會改變成本計算的地方。自 iOS 16.4 起，Safari 已支援加入主畫面的網頁應用程式發送推播通知。Chrome 取消了安裝對 Service Worker 的要求。英國主管機關在 2025 年 10 月認定 Apple 與 Google 在行動瀏覽器與瀏覽器引擎上具有策略市場地位。同時 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。後台管理介面不會告訴你人們是否想要這個產品；它只會告訴你，等人們想要之後，這個產品會更好管理。把它放到第二...