客製化 Web 應用開發與現成 SaaS 比較

幾乎沒有哪個客製化 Web 應用開發專案是從一份規格書開始的。它通常始於一張試算表，某個人為了追蹤一件事而建立，後來加了第二欄，再後來多了一個工作表，最後加進一條只有一個人看得懂的公式。三年之後，那個檔案裡裝著排程、價格和一半的客戶資料，四個人同時在編輯它，而沒有人能有把握地說出哪一份副本才是最新的。

那才是真正的決策點，也是多數自建與採購之爭的文章沒有觸及的地方。你要選的並不是一張白紙和一件成品。你要選的是從一套還能運作但已經很脆弱的流程中脫身的三條路：買一個產品，在無程式碼平台上拼裝一個，或者依照自己的做事方式委外開發一套軟體。

該開發客製化 Web 應用，還是採購 SaaS？ 預設是採購，除非三個條件裡至少成立兩個：這項流程是競爭上的差異化優勢而不是間接成本；沒有任何產品能在不扭曲你做事方式的前提下適配它；以及整件事的主體工作是系統整合。如果只成立一個，買產品再加設定幾乎總是更便宜。客製化開發還帶著一條持續的成本底線，大約是建置價格的 15 到 20 個百分點，每年都要付，而且永遠不會停。

變成業務支柱的那張試算表

這個模式具體到可以替它取個名字，而通常正是被點名之後，團隊才認出自己。

它始於一個人和一個目的。有人需要知道這週排了哪些案子，於是打開一張表。第二個人需要讀它，於是它搬到了共用磁碟上。第三個人需要編輯它，於是現在多個人同時往同一批儲存格裡打字。接著是按月拆分的工作表。接著是對第二個檔案的查表參照。接著是一段巨集，作者是一位早已離職的外包人員。

徵兆是一致的。檔名裡帶著日期和版本後綴。有一份正本，而且所有人都知道它在誰手上。新人到職的方式是被人帶著看那個檔案，而不是被告知流程，因為流程沒有寫在別的任何地方。

到了這一步，這張試算表已經不是文件了。它是一個應用程式，沒有存取控制，沒有稽核軌跡，沒有輸入驗證，沒有一份你敢拿出來辯護的備份政策，而且只有一位維護者。它能用，這正是沒人替換它的原因，也正是現在替換它會很貴的原因。

維持現狀實際付出的代價

沒有人替試算表算過帳，所以它看起來是免費的。它並不免費，而這筆帳用你自己公司的數字很容易算。

先從重複輸入算起。如果兩個人每天各花 45 分鐘，在表格、會計軟體和共用信箱之間搬運資料，那就是每週七個半小時，以一年 45 個工作週計算約為 340 小時。以含用人成本的每小時 GBP 22 計，你每年花掉約 GBP 7,500 把數字從一個畫面抄到另一個畫面，而這筆錢買到的只有出錯的機會。

再加上對帳，每個月有人拿表格去核對真正的帳，花半天判斷哪個版本是對的。再加上遲遲才被發現的錯誤：按上個月價格發出的報價、重複排入的工單、錯過的續約。每一件都是一筆小錢和一位不高興的客戶，而且沒有一件出現在任何預算科目裡。

再加上關鍵人物風險。只有一個人真正理解那些公式，當這個人生病、休假或離職時，流程就退化成猜測。

試算表裡的個人資料同樣是受規範的資料

如果這個檔案裡有姓名、聯絡方式、員工紀錄或客戶資訊，它就是個人資料，英國 GDPR 對它的適用方式與對資料庫完全一樣。

ICO 對此說得很直接。其資料安全指引指出，英國 GDPR 的一項關鍵原則是透過適當的技術與組織措施安全地處理個人資料，而這些措施必須確保你的系統以及其中個人資料的機密性、完整性與可用性。筆記型電腦上的一張試算表沒有列層級權限，沒有保存期限規則，沒有誰讀過什麼的紀錄，而且每次有人用電子郵件寄出它，它就完整地複製一份。

後果不是紙上談兵。2024 年 10 月，ICO 對北愛爾蘭警察局處以 GBP 750,000 的罰鍰，原因是一份依資訊自由請求公開的試算表中的隱藏資料，暴露了全部 9,483 名 PSNI 警員與職員的姓氏、名字縮寫、警階和職務。那份執行通知引用了第 5 條第 1 項(f)款、第 32 條第 1 項和第 32 條第 2 項。若沒有 ICO 面向公部門的處理方針，這筆罰鍰會是 GBP 5,600,000。

每一個用試算表撐起流程的機構，某處都藏著這樣一張工作表。

採購產品：SaaS 明顯正確的時候

這是多數情況下的答案，它值得被放在最前面論證，而不是在結尾段落裡被草草打發。

如果你的流程是常見流程，那麼產品已經存在，而且比你能做出來的任何東西都便宜。薪資發放、費用報支、服務台工單、預約、電子簽章、記帳、徵才管理。有人已經用十年時間和一支龐大的工程團隊，去處理你還沒遇過的邊角情況：閏年的錯誤、加值稅稅率的調整、結帳期之後才到的退款。

你買到的還有本來要自己掏錢的勞務。供應商承擔了可用率、安全性修補、瀏覽器的持續變動、無障礙工作，以及你的客戶會索取的法遵佐證。這些都不會以一項功能的樣子出現，而它們全都是真金白銀。

誠實的檢驗標準不是這個產品是不是什麼都能做。而是它能不能在不逼你改變任何你在乎的東西的前提下，做好重要的那 80 個百分點。如果唯一的落差是你的團隊說案子而軟體說工單，那就買下軟體，改掉那個詞。

讓客製化 Web 應用開發站得住腳的三個條件

支撐客製化開發的是策略，不是惱火。真正站得住腳的條件有三個，而有用的規則是你至少需要其中兩個。只有一個條件時，用產品加設定去解決幾乎總是更便宜。同一套檢驗在企業規模上同樣成立，我們的 CRM 與 ERP 自建或採購指南在另一個數量級上討論了它。

這項流程是差異化優勢還是間接成本

問問看，如果這項流程好上一倍，客戶會不會察覺。如果答案是不會，那它就是間接成本，你應該買，因為薪資發放做得再出色也贏不來生意。但一家專業安裝公司，如果它的排程邏輯能讓每台車每天多跑一單，或者一家放款機構的授信規則本身就是它的產品，那它就是在透過那套軟體運轉競爭優勢。你無法買到一個競爭對手能用同樣月費買到的優勢。

沒有產品能在不扭曲流程的情況下適配

每個產品都把關於工作如何流動的假設寫進了自己內部，而它們不適合你的訊號是：採用這個產品會要求你停止做某件正在賺錢的事。如果你報價所依據的基礎是產品表達不出來的，而客戶正是因為這種報價方式才選擇你，那麼這個產品是在用一筆授權費，換你變得更平庸。

整合面才是真正的工作

有時候有意思的部分根本不是那些畫面。而是從一個系統拉庫存，從第二個系統拉價格，從第三個系統拉工程師的可用時段，再把結果寫進第四個系統。當大部分工作量是整合時，使用者介面只是覆在你自家管線上的一層薄殼，而產品內建的畫面恰恰是你最不需要的部分。這個條件最常被低估，中間陷阱也正藏在這裡。

中間的陷阱：買了，最後還是自己做

最貴的結局是兩條路都沒有走乾淨。它是因為看起來便宜而買下一個產品，然後為了把它折成你的流程，花掉比客製化開發更多的錢，同時還在繼續付授權費。

它是逐步發生的，而且每一步單獨看都站得住腳。產品不合適，於是你請來導入夥伴。夥伴在供應商專有的指令碼層裡寫設定，那是程式碼，但因為它住在產品內部，所以感覺不像程式碼。接著你需要它和另外兩個系統對話，於是你買了一個整合平台。接著供應商推出了一個大版本，你的客製內容需要迴歸測試。

到那個時候，你已經承擔了客製化軟體的全部成本，卻沒有得到任何所有權：一套你讀不懂的程式碼庫，代管在你不掌控的地方，用一種只存在於一個產品裡的語言寫成，由一位日費如今成為你預算科目的夥伴維護。我們關於客製化軟體開發成本的指南講了這些數字是怎麼累積起來的。

你已經落入陷阱的警示訊號

陷阱容易發現，難的是脫身，而只要去找，訊號是明確的。

• 導入夥伴的費用大於第一年的授權費。
• 有人的全職工作實際上就是管理一個產品。
• 你用供應商專有的指令碼語言寫了商業邏輯，公司之外沒有人讀得懂。
• 供應商每次升級都會觸發對你客製內容的迴歸測試，於是你一再延後升級。
• 你在為一個整合平台付費，而它存在的唯一目的就是餵資料給這一個產品。
• 你在產品之外還維護著一張影子試算表，因為產品表達不了某個你需要的東西。

最後一條最清楚。如果試算表在軟體採購之後依然活著，那麼這套軟體並沒有解決問題。

把無程式碼與低程式碼當成認真的第三條路

無程式碼還是客製化這個問題不該被當成註腳，因為在內部工具開發上，低程式碼平台常常就是正確答案，而且它們不是玩具。

Airtable、Retool 和 Microsoft Power Apps 這類平台，讓你在不招人的情況下，用幾天而不是幾個月，做出一個真正的多使用者應用，帶資料庫、表單、權限和自動化。它們負責主機代管、備份、身分驗證和行動版版面。對於把一張已成業務支柱的試算表搬進一個具備正經存取控制與稽核軌跡的東西裡這件具體的事，它們常常是把風險大幅降下來的最快路徑。

它們同樣按席次計價，而正是這個事實決定了隨著你成長，它們是否還是正確答案。

無程式碼真正取勝的地方

當問題的形狀是紀錄、表單、檢視和簡單規則時，它取勝：一份資產清冊、一條簽核佇列、一張客戶導入檢查表、一套會議室預約。它贏得最徹底的時候，是懂這套流程的人能自己把它做出來，因為需求不必再經歷翻譯成規格書又翻譯回來的過程。

它在見效時間上也取勝。一個兩週做出來、每天都在用的工具，勝過一個六個月後才完美卻還停在設計階段的工具，而且做出來的那一版會告訴你真正的需求本來是什麼。

無程式碼撞牆的地方

那堵牆通常是五件事之一。真實資料列數下的效能，一旦某個檢視必須在數十萬筆紀錄裡做篩選。任何有點複雜度的權限，例如取決於紀錄狀態和檢視者所屬團隊的列層級規則。交易完整性，兩件事必須同時成立或都不成立。測試與版本控制，因為往往沒有辦法在變更上線前先做審查。以及任何帶有真正狀態機的東西，由規則決定哪些轉換是合法的。

你不會慢慢撞上那堵牆。你撞上它，是在某個本該一小時完成的變更被發現根本做不到的時候。

按席次計價在規模上會做什麼

按席次計價在十個人時很便宜，在四百人時可能難以辯護，而公開的費率讓這一點很容易示範。

Retool 的定價頁列出其面向英國雲端的 Business 方案為每位建置者每月 GBP 40、每位內部使用者 GBP 12，Team 方案則是 GBP 8 和 GBP 4。Microsoft 列出的 Power Apps Premium 為年繳時每位使用者每月 GBP 16.90，未含加值稅，在 2,000 個席次起訂時降到 GBP 10.80。Airtable 公布 Team 為每位使用者每月 USD 20，Business 為 USD 45，兩者都以美元按年計費。

把這些往前推算。在 Retool Business 上用 40 位使用者，其中 3 位是建置者，一年約合 GBP 6,800。同樣的結構放到 400 位使用者上，一年大約是 GBP 59,600，而且你一加人它又會往上走。換成 Power Apps Premium，400 個席次一年在加值稅之前約為 GBP 81,000。

這些費率沒有一條是不合理的。重點在於帳單跟著人頭走，而不是跟著交付的價值走，而人頭會成長。

當商業邏輯住在專有工具裡時的退出問題

每個平台都會把你的資料匯出來。沒有一個平台會把你的應用匯出來。

那些資料列會以 CSV 或透過 API 出來，而這也正是所有人簽約前都會檢查的部分。出不來的是你親手做起來的那些東西：自動化、公式欄、權限規則、條件式表單，以及那條把一次申請變成三則通知和一次狀態變更的流程。那套邏輯才是資產，把它做對花了好幾個月的判斷，而能執行它的只有一家供應商的執行環境。

實際後果是，離開一個低程式碼平台不是移轉，而是重建。你把資料拿回來，然後在別處把這個應用重新寫一遍，而依據的規格書從來沒有被寫下來過，因為平台本身就是規格書。

這不是反對使用它的論據，只是主張把規則的書面描述放在工具之外。

三條路的五年總持有成本

人們通常做的那種比較，在一個特定的地方並不誠實：它把一條路的完全成本版本，拿去對另一條路的標價。設想 40 位使用者，以及一個取代一張試算表和兩項小額訂閱的營運應用。下面的數字是用於規劃的示意性數字，不是報價，而其中變動最大的變數是你的建置價格。

用文字來讀：在 40 位使用者時，無程式碼平台勝出，五年約 GBP 75,800。客製化開發以約 GBP 94,500 位居第二，因為 GBP 45,000 的建置費加上 GBP 1,800 的主機代管和每年 GBP 8,100 的維護，仍然低於 SaaS 路線疊起來的授權、中介軟體和管理成本。採購產品以約 GBP 135,000 墊底，而它之所以墊底，是因為中間陷阱，而不只是因為授權費。

為什麼同一張表在四百位使用者時會反轉

只改一個輸入，也就是人頭數，排序就完全變了。這是客製化開發變得合理的最常見原因。

在 400 位使用者時，每席每月 GBP 30 的 SaaS 授權費單項就是一年 GBP 144,000，再加上同樣的中介軟體和更重的管理負擔，五年合計會超過 GBP 800,000。無程式碼路線落在約 GBP 375,000。客製化開發幾乎不動：使用者更多意味著主機帳單和維護預算略大一些，所以即便把建置價格加倍到 GBP 70,000，五年合計仍在約 GBP 153,000。

原因是結構性的。按席次計價是一項隨組織規模變動的變動成本，而客製系統是一項固定成本加一小筆變動成本，那筆變動成本是基礎設施，而基礎設施很便宜。這個反轉對你是否重要，是一道業務預測題，而不是一道技術判斷題。

客製化開發的持續成本底線

人們從客製估算裡漏掉的那一行，正是永遠不會停的那一行。客製應用有一條成本底線，而且在沒有人提需求的清閒年份裡，它也不會降到零。

這條底線由主機代管、監控、你真正演練過還原的備份、TLS 憑證、安全性修補、相依套件升級，以及週一早上九點它壞掉時接電話的那個人組成。請按原始建置成本的大約 15 到 20 個百分點做年度規劃。那是一條從這類專案實際表現中得出的規劃假設，而不是一項公開發布的統計數字，但它是我們編預算時使用的數字，而一份沒有把它算進去的報價不是完整的報價。我們關於軟體維護成本的文章對此有更細的拆解。

上面每一個五年客製合計都假定這一行有預算。跳過它的專案並沒有省下這筆錢，只是把它延後了，然後以一次重寫的形式付掉，而這正是技術債所描述的東西。

不維護的軟體會腐壞

一個兩年沒動過、一直在跑的應用並不是穩定。它是沒修補，而這個差別很重要。

你的程式碼什麼都沒變，但它周圍的一切都變了。語言執行環境按公開的時程走到生命週期終點：Node.js 目前把版本 26 當作 Current，把版本 24 和 22 當作活躍的 LTS 分支，這代表任何建立在版本 20 或更早之上的東西現在都已脫離支援，收不到任何安全性修正。相依套件會累積已公開的漏洞。瀏覽器會改變對待 Cookie 和儲存空間的方式。金流服務商會終止 API 版本，並給你一個期限。

這些都不是你的錯，而它們全都是你的問題，因為在客製系統裡沒有供應商替你吸收它們。這是採購真正的、結構性的優勢：別人的工程團隊每週都在防止地板腐爛，而授權費就是這件事的價錢。你自己的維護預算買到的是完全相同的工作，你要麼有計畫地付它，要麼在一次緊急事件裡付它。

找到你自己的席次反轉點

這個反轉點大約十分鐘就能算出來，而且它比任何關於所有權的論證都更能說服財務長。

把產品路線的每月成本以全口徑取出來：授權費、中介軟體，以及花在管理它上面的那部分薪資。減去客製系統的每月營運成本，也就是主機代管費加上年度維護預算的十二分之一。用建置價格除以剩下的差額。答案就是這套系統回本所需的月數。

以 40 位使用者計算：SaaS 路線每月約 GBP 2,150，客製系統每月約 GBP 825，於是每月省下約 GBP 1,325。GBP 45,000 的建置費除以它約為 34 次，所以回本落在大約兩年十個月。在 400 位使用者時，回本會縮短到一年以內。

兩點提醒。建置價格是這裡最不確定的數字，所以請按你拿到的報價算一次，再按高出 50 個百分點算一次。另外，回本期長於大約三年就是一個薄弱的理由，因為你的流程未必能原樣存續那麼久。

資料與鎖定是雙向的

供應商鎖定是支持自建的標準論據，而且它是真實存在的。它同時也只是一半的樣貌，因為一套沒有人寫過文件的客製系統同樣被鎖住了。

在產品這一側，簽約之前先確認到底能匯出什麼。紀錄通常匯得很乾淨。附件、歷史稽核紀錄、留言串、權限結構，以及紀錄之間的關聯，則經常匯不出來。務實的衡量標準不是有沒有一個匯出按鈕，而是你能否僅憑這份匯出就架起一套可用的替代系統。

在客製這一側，等量而相反的風險是一套由一位外包人員做成的系統：沒有 README，沒有測試，沒有維運手冊，憑證放在某台筆電的設定檔裡，程式碼儲存庫在某個人的個人帳號底下。那比 SaaS 鎖定更糟，因為供應商至少還在營業。

補救辦法是合約層面的，而且在一開始就堅持要它們很便宜。儲存庫由你自己擁有，把文件和維運手冊列為具名交付項目，並要求第二位工程師僅憑這份文件就能完成部署。在付尾款之前驗證這個說法。我們的完整採購方指南更詳細地講了合約條款。

每種模式下的資安與法遵

責任的劃分因路線而異，但有一樣東西完全不動，而弄錯這一點很常見。

在英國 GDPR 之下，你是控制者。ICO 把控制者定義為單獨或與他人共同決定個人資料處理目的與方式的主體，把處理者定義為代表控制者處理個人資料的主體。你的 SaaS 供應商幾乎總是處理者。證明法遵的責任仍然在你，而且 ICO 明確指出，控制者要為其處理者負責，並且必須簽訂一份包含第 28 條第 3 項所要求條款的具有拘束力的合約。

供應商真正承擔的是基礎設施層：實體安全、平台修補、網路控管，通常還有各類驗證。NCSC 的責任共擔模型講得很清楚，即便是 SaaS，你仍保留三件事：評估這項服務是否滿足你的資安需求、把它設定妥當，以及決定要把哪些資料放進去。

在客製化開發裡，你還會一併繼承整個技術層：修補、存取控制、加密、記錄、備份與還原。我們關於 GDPR 技術法遵的文章講了這在程式碼裡是什麼樣子。法律地位不會因為路線不同而改變。

無障礙規則同樣適用於內部工具

內部工具經常被當作使用者不可能有身心障礙那樣來打造，這既是錯的，對某些機構而言還是違法的。

依據《2010 年平等法》第 20 條，雇主有義務做出合理調整，包括採取合理可行的步驟來避免某項規定、標準或做法所造成的重大不利，並提供輔助器具。一套無法用鍵盤操作的排班系統，會讓一位身心障礙員工處於重大不利之中，而且並不存在因為軟體你的客戶永遠看不見就可以豁免的說法。

對公部門機構來說，這一點是明文規定的。GOV.UK 關於無障礙要求的指引指出，內部網站和外部網站也在無障礙法規涵蓋範圍內，它們必須符合 WCAG 2.2 AA，而在 2019 年 9 月 23 日之前發布的較舊內部網站，在更新時必須做到無障礙。

內部工具最常沒做到的準則都是些平淡無奇的條目：A 級的 2.1.1 鍵盤和 3.3.2 標籤或指示，AA 級的 1.4.3 對比度（最低要求），以及 WCAG 2.2 新增裡的 2.4.11 焦點不被遮蔽（最低要求）和 2.5.8 目標尺寸（最低要求），後兩項也都是 AA 級。

在無程式碼上，無障礙的天花板不由你掌控

這是那個會改變自建與採購決策、而不只是替決策加上一些工作量的無障礙論點。

在無程式碼平台上，標記不是你寫的。是平台產生的，所以你的應用的無障礙水準被平台元件庫的水準封頂。如果它的日期選擇器無法用鍵盤操作，或者它的互動視窗焦點處理很糟糕，你修不了。你能做的是開一張支援單，然後等。

當天花板夠高時，這沒問題，而且有好幾個平台確實認真看待這個問題。當你有一項具體義務、一位具體員工或一份公部門職責時，這就有問題了，因為補救手段既不在你的掌控之內，也不在你的時程之內。

在客製化開發裡，無障礙工作是你自己要做對的事，它前期更貴，但去掉了這層相依。在圍繞某家供應商的元件設計流程之前，先向它索取一份無障礙符合性聲明，並把它拿不出來這件事本身當成一個答案。

用一片薄薄的第一切片替客製化開發降風險

客製專案失敗的方式通常不是技術性的。它是把全部預算押在一份寫於任何人使用任何東西之前的規格書上。

替代方案是一片薄切片：一條工作流程，端到端，跑在正式環境裡，由一位做著真實工作的真實的人使用，在六到八週內完成。它不是雛形，也不是展示，而是穿過系統、能產生真實成果的最窄那條路徑，帶著真實資料、真實身分驗證和一次真實部署。如果流程是報價，那麼這片切片會產生一份報價、替它定價並寄出去。

這片切片能做到四件規格書做不到的事。它驗證了各項整合，而意外正藏在那裡。它測量團隊真實的交付速度，而不是估計它。它把可運作的軟體擺在流程主人面前，而這必然會改變需求。它還給了你一個退場口：你花掉的是一筆確定的錢，而你擁有了一件能用的東西。

然後在那裡設一個決策點，寫下來，放在更大的一筆支出被釋出之前。我們關於如何打造 Web 應用的指南講了第一片切片的技術樣貌，而我們的軟體開發服務頁面說明了我們如何界定它的範圍。

一個下午就能跑完的決策架構

這些都不需要一份顧問合約。它需要的是幾個小時，以及對數字的誠實。

第一，把流程按它實際運作的樣子寫下來，分成步驟，包括人們用手工處理的那些例外。光是這一步往往就結束了爭論，因為它會揭露出這裡其實有三條流程，而不是一條。

第二，數清今天的席次數，並預測三年後的席次數。第三，恰好篩出三個產品，拿它們去對你寫下來的流程評分，而不是對它們的功能清單評分，把每一處採用該產品就會改變你做事方式的地方都標出來，並記下那種改變是否讓你付出代價。

第四，明確地替中間陷阱定價：導入費用、中介軟體，以及將要用來管理它的那部分薪資。第五，套用三取二的檢驗。第六，在兩個席次數下分別算出以月計的反轉點。第七，如果答案是客製，那就先訂一片薄切片，而不是一整套系統。

誰應該關掉這個頁面去買現成的

有些讀者應該在這裡停下，而把這一點說明白，比給一個四平八穩的結論更有用。

如果你的流程是成千上萬家企業以大致相同方式運作的常見流程，買產品。如果你的使用者少於大約二十人，而且沒有會改變這一點的預測，那就買產品，或者在無程式碼平台上把它做出來，因為在你能規劃的任何時間範圍內，席次算術都不會轉向對你有利。如果軟體交付之後沒有人會擁有它，買產品，因為一套無人擁有的客製系統會很快腐壞成一項負債。

如果你無法用文字描述你的流程，現在還不要訂任何東西。先把它寫下來。許多失敗的專案，是照著一份同一個房間裡的三個人各自理解不同的描述訂下來的，而這一點不是任何工程能力能修復的。

如果三個條件裡只成立一個，買產品，一年後再回頭看。條件是會變的，通常是因為人頭增加了。而如果你真正需要的是一個面向大眾的網站而不是一個內部工具，那是另一個專案，屬於我們的網站開發業務。

在你做出承諾之前聽一個第二意見

無論朝哪個方向，那個昂貴的錯誤都是在任何程式碼存在之前就犯下的，所以你現在能買到的最便宜的東西就是一份誠實的評估。

Mecanik 為英國企業打造營運型 Web 應用，而這份工作中很大一部分，是告訴人們他們並不需要一個。把那張試算表、席次數，以及你篩出來的三個產品帶過來，我們的客製化軟體開發團隊要麼替第一片薄切片報個價，要麼告訴你應該改買哪個產品。如果這個應用是面向客戶而不是面向內部的，請從網站開發開始，並讀一讀討論那一側問題的客製化 Web 開發與 SaaS 平台比較。

常見問題

在英國做一個客製化 Web 應用要花多少錢？ 一個取代一張試算表和一兩項訂閱、目標明確的內部應用，建置費用通常在 GBP 25,000 到 GBP 60,000 之間，其中一片薄薄的第一切片占 GBP 8,000 到 GBP 15,000。此外每年還要按建置價格的 15 到 20 個百分點預留主機代管、修補和相依套件升級的費用，因為這條成本底線永遠不會降到零。

無程式碼是客製化 Web 應用開發的真正替代方案嗎？ 是。對於紀錄、表單、檢視和簡單規則，它常常就是正確答案，而且快得多。它會在大量資料列、複雜權限、交易完整性、版本控制和真正的狀態機上撞牆。它同樣按席次計價：Retool 列出其 Business 方案為每位建置者每月 GBP 40、每位內部使用者 GBP 12，這在十個席次時很便宜，在四百個席次時就是一筆可觀的開銷。

使用者數到多少時自建會比採購更便宜？ 用建置價格除以每月省下的金額，也就是產品的全口徑成本減去主機代管費加上年度維護預算的十二分之一。在 40 位使用者時，一筆 GBP 45,000 的建置費對上每月 GBP 2,150 的產品成本，大約 34 個月回本。在 400 位使用者時，一年之內就能回本，因為席次費隨人頭成長，而客製系統的營運成本幾乎不動。

如果我們採購 SaaS 而不是自建，資料保護由誰負責？ 由你負責。ICO 把控制者定義為決定處理目的與方式的主體，而你的 SaaS 供應商幾乎總是依你的指示行事的處理者。證明法遵、你的處理者的法遵，以及一份符合第 28 條第 3 項的合約，責任都仍然在你。採購軟體移轉的是基礎設施工作，不是法律責任。

公司之外沒人看得到的內部工具也要遵守無障礙規則嗎？ 要。《2010 年平等法》第 20 條要求雇主做出合理調整，而一件無法用鍵盤操作的工具會讓身心障礙員工處於重大不利之中。公部門的內部網站和外部網站還額外受無障礙法規涵蓋，必須符合 WCAG 2.2 AA。在無程式碼平台上，無障礙的天花板由供應商的元件決定。