每個來找我們的客戶，雖然站在同一條旅程上，落點卻都略有不同。有的人有清楚的功能清單與截止日。有的人帶來的是一個問題（「我們員工每天花兩小時把同一筆資料抄在三個系統之間」），但完全不知道解法長什麼樣。下面這條流程，是我們多年下來在做網站、資訊管理系統、行動 App，以及維運託管的過程中淬鍊出來的標準作業。專案大小不影響流程形狀，影響的只是每個階段做多深。
第一階段——訪談與範圍界定（第 1 週）
我們從一場 90 分鐘的需求訪談開始，現場或遠端都可以。第一週的目標不是動工，是確認我們要做的是對的事。我們會把現況流程畫出來、把痛的工作項列出來、定義誰才是真正的使用者（常常和付錢的人不是同一個），再用三個可量化的數字定義「成功」長什麼樣。週末客戶手上會有一張單頁的 scope 文件，他拿去公司內部給任何人看都不用解釋。
第二階段——架構與提案（第 2 週）
把訪談結論翻成具體的技術提案。網站類：技術堆疊（多半是 Laravel + MySQL + Nginx，前端 Tailwind）、頁面樹、內容模型。資訊管理系統類：實體模型、依角色設計的權限矩陣，以及與客戶既有系統（會計、ERP、電商、看板系統）的整合點。行動 App 類：平台決策（跨平台預設 Flutter）、API 合約、離線優先的行為。交付物是清楚的價格、清楚的時程、以及一份「我們不會做這些」的清楚清單。
第三階段——設計與原型（第 3~4 週）
設計不是「把它做漂亮」。設計是「讓真的會坐在前面用八小時的那個人用得下去」。我們很早就會做出可點擊的原型——通常設計開始的前十天內——放在兩三位真實使用者面前。我們看著他們嘗試完成任務，不解釋。每一次點錯，都是免費的資訊。最後出貨的設計，跟第一版幾乎都不一樣。
第四階段——建置（第 4~10 週，依範圍）
建置以雙週為一個 sprint。每個 sprint 結束，客戶看得到實際可運作的東西——不是投影片、不是截圖，是 staging 環境中可登入的軟體。建置期間我們不退讓兩件事：每一個功能上線都帶測試，每一次資料庫變更都帶可倒回的 migration。這不是奢侈品，這是第 31 天還能順利的真正原因。
第五階段——上線前加固（上線前一週）
上線前一週，從寫功能切換到加固。資安巡檢：Laravel 端的輸入驗證、CSRF、rate limit、SQL 參數化、相依套件漏洞掃描。效能巡檢：慢查詢的執行計畫、Nginx 快取、圖片壓縮、靜態資源打包。SEO 與 AEO 巡檢：schema 結構標記、sitemap、可被 AI 引擎引用的 FAQ 結構區塊。備份還原演練：因為確認備份真的能還原的好時機，是「第一次出事之前」，不是「正在出事的時候」。
第六階段——上線與前 30 天
第 0 天是上線。第 1~30 天是穩定化。我們盯每一條錯誤、每一筆慢請求、每一次登入失敗。多數專案第一週都會跑出一張「staging 沒看到」的小清單；我們會在 24 小時內修掉。第 30 天，專案進入正常維運節奏：每週自動備份、每月安全性更新、每季架構檢視。
持續服務——託管與維運
願意把基礎建設交給我們的客戶，我們會繼續跑下去。內容包含一套加固過的 Nginx + Laravel + MySQL，異地每日備份、自動 TLS 續簽、入侵偵測告警，以及有明確 SLA 的回應時間。自己跑基礎建設的客戶，我們會交出同一份 playbook 與相應文件。不管哪一條路，目標是一致的：客戶第一週付錢買的那套系統，五年後還在接電話。
我們不會承諾的事
我們不會在範圍真的還不清楚的時候給固定報價——先訪談、再報價。我們不會承諾用兩週做十週的事。我們也不會去做我們認為客戶不該做的東西；如果訪談結果是「你比較應該買一套 SaaS 然後設好它」，我們會直說。我們相信，關係比那張請款單值錢。