網頁應用程式、SaaS 與 MVP 開發

網頁應用程式或 MVP 專案包含哪些內容#

我們會依照實際需求來規劃合作方式。報價提案中會說明包含哪些交付項目、由誰提供所需素材,以及每個項目如何驗收。

• 第一版範圍:核心工作流程、角色,以及暫緩的項目
• 設計關鍵畫面,並涵蓋空白、載入與錯誤狀態
• 資料模型、伺服器端存取規則,以及試圖突破這些規則的測試
• 帳號、角色與團隊邀請
• 透過經驗證的服務商回呼來確認付款或訂閱
• 後台管理介面、產品分析事件與錯誤監控
• 部署、文件,以及程式碼儲存庫與帳號的交接

該先做網頁應用程式、網站,還是產品設計?#

如果顧客或員工需要登入產品並完成工作,例如購買、預約、提交、核准或管理某些事項,就適合選擇這項服務。如果您需要的是介紹並推廣您的產品或服務的網站,網站開發會更合適。如果工作流程尚未確定,建議先從產品設計開始,等關鍵畫面經過使用者測試後再進行開發。

第一版是如何打造的#

我們會先進行範圍界定階段:釐清使用者與角色、第一版必須完成的那一個工作流程、每個步驟產生的資料,以及會影響成本的決策,例如付款、系統整合與權限。產出包括書面範圍說明、可點擊操作的關鍵畫面,以及標明哪些項目延後的發布計畫。

接著我們以短週期在您可以實際使用的測試環境中進行開發。第一個里程碑是讓核心工作流程的精簡版本從頭到尾跑通,並採用真實的登入機制與資料規則,之後再補齊其餘畫面。上線時會一併提供正式環境監控與回復機制,並將程式碼儲存庫、主機、資料庫、付款與數據分析帳號,全數移交到您的名下。

MVP 的第一版該包含什麼?#

第一版需要具備讓真實使用者完成一個工作流程的所有必要功能,而不需要那些在您尚未達到的規模下才有意義的東西。實際上包含五項:具備工作流程所需角色的帳號、核心工作流程本身、讓團隊不用靠工程師就能查看與修正資料的後台管理介面、商業模式從第一天就收費時所需的付款功能,以及能顯示使用者在哪裡中斷的分析事件。

可以人工處理或日後再購買的項目就先延後:原生行動應用程式、企業客戶的單一登入、可自訂的權限矩陣、第二個系統整合、應用程式內聊天,以及沒有人要求的報表。每個延後的項目仍會在範圍文件中列上一行,讓資料模型預留空間。

大多數產品都是由常見的模組組合而成。其中有兩個值得特別說明:預約與排程,以及適用於目前仍以人工追蹤詢問的小型企業的潛在客戶管道。兩者看似簡單,卻隱藏了關於時區、狀態與負責人的決策,事先在紙上釐清成本更低。

Dardo 使用哪種技術堆疊?什麼情況下會選擇不同的方案?#

我們的預設方案是全程使用 TypeScript:以 Astro 處理伺服器端渲染的頁面與互動式島嶼元件,以 Cloudflare Workers 負責代管與 API,資料使用 Cloudflare D1 或 Postgres,並以 PostHog 進行數據分析與實驗。Superame 採用 Astro 建置,排名資料則存放在 Neon Postgres。單一語言與單一部署目標,能讓小型產品更容易營運與交接。

當產品有需要時,我們會選擇不同的方案。需要整天開著的高密度介面,可能適合採用用戶端 React 應用程式,例如 Shiimain 原型。長時間執行的工作、大量資料處理,或是內部團隊已經習慣使用其他框架,也會改變我們的選擇。如果上線後由您的開發人員接手程式碼,通常會以他們熟悉的技術堆疊為優先。

存取控制是我們最先測試的項目。OWASP Top 10:2025 仍將「失效的存取控制」(Broken Access Control)列為第一名,並指出所有受測的應用程式都存在某種形式的此類問題。我們會在伺服器端針對每個請求強制執行權限、預設拒絕、將每次查詢限定在已登入使用者所屬的組織範圍內,並撰寫自動化測試,嘗試讀取其他顧客的資料。

網頁應用程式的付款流程該如何設計?#

付款是否成功,應由金流服務商在伺服器端確認;瀏覽器從結帳頁返回時,絕不能作為確認依據。Dardo 已公開作品中的公開專案排行榜 Superame 就是這種做法的範例。買家在 Dodo Payments 的託管結帳頁面付款,因此信用卡資料不會經過應用程式。接著,服務商會發送附有簽章的回呼通知,伺服器會先驗證簽章並核對付款明細,才會增加額度。

退款與爭議款項也走同樣的流程。每個服務商事件只會被處理一次,因此即使回呼通知重複送達、延遲送達或順序錯亂,也不會重複增加或扣除額度。Superame 並未公布任何使用率或營收數據;它只能證明付款邏輯是如何建置的,而不能證明銷售成果。

• 買家若在頁面跳轉前就關閉分頁,回呼通知送達後仍會入帳。
• 重送或偽造的回呼通知會被拒絕。
• 退款或爭議款項會精確撤回原始付款所給予的內容。
• 方案限制會在伺服器端檢查,而不是只在介面上隱藏。
• 測試與正式環境的金鑰是各自獨立的機密資訊,絕不存放在程式碼儲存庫中。

讓您的客戶使用自己的網域#

B2B SaaS 的客戶通常希望產品能使用自己的網址,例如 portal.theircompany.com。Cloudflare for SaaS 透過自訂主機名稱來處理這件事:Free、Pro 和 Business 方案內含 100 個,每多一個主機名稱收費 $0.10,上限為 50,000 個。萬用字元自訂主機名稱僅限 Enterprise 方案使用。

您的客戶需要新增一筆 CNAME 記錄,指向您的目標位址。若要使用 A 記錄指向該目標(根網域就需要這樣做),預設並不支援,而根網域代理是 Enterprise 的加購項目,因此大多數客戶應該使用子網域。憑證可透過 HTTP、TXT 或電子郵件驗證,也可使用 Delegated DCV,這是一筆一次性設定的記錄,可讓 Cloudflare 自動續期憑證。憑證由 Let's Encrypt、Google Trust Services 或 SSL.com 核發。

周邊的產品設計同樣重要:只有付費方案才能綁定網域、引導畫面會顯示需要新增的確切記錄、驗證狀態會用淺顯易懂的文字說明待處理與失敗的情況,而當客戶變更 DNS 導致憑證無法續期時,監控機制會通知您的團隊。其他主機服務的限制各不相同:Vercel 在 Hobby 方案中每個專案允許 50 個網域,Pro 與 Enterprise 方案則不限,軟性上限分別為 100,000 和 1,000,000;Netlify 建議每個網站的網域別名不要超過 50 個。

選擇前的常見疑問#

部落格文章#

• SaaS 自訂網域:用 Cloudflare for SaaS 讓客戶使用自己的網域

  透過 Cloudflare for SaaS,讓客戶把自己的網域指向你的 SaaS:驗證如何運作、截至 2026 年 10 月的費用,以及哪些地方會出問題。