大多數中小企業已經付過一次這種帳：預算超支 30%、上線晚了一季、做完之後發現負責人「以為很明顯」的整合根本沒做。原因幾乎從來不是工程師寫不出程式碼，而是專案開工時，沒人先把「上線當天會成立的事實」講清楚——只要這個模糊存在，每次現實打破假設，重新報價就會發生一次。
有紀律的「網站 + 資訊管理系統（IMS）+ App」整合 greenfield（全新建置）專案，中等規模是 90 天，較大規模是兩個 90 天循環。下面這個架構是我們內部跑的版本，也是 day one 就交給客戶的時間表——讓時程不是黑盒子。它涵蓋規劃、建置、那些常常踩坑的「不顯眼」考量、以及託管的整套故事。
第 1–2 週：發現與範疇
前兩週不是「開始寫」，是這個專案能買到最便宜的保險。產出有四份文件：一頁式產品 brief（誰是使用者、他離開系統時完成了什麼、生意上量什麼）、功能盤點（拆成「上線必備」「上線時 nice-to-have」「上線後做」）、資料模型草圖（IMS 會持有的每一個 entity）、託管與整合地圖（系統會呼叫的每一個第三方服務）。
這個階段最「不顯眼」的產出是「需要客戶自己決定的事項清單」。多數超時不是工程錯誤，而是「沒人標記為需要人類抉擇」的決定。「客戶在年費訂閱第二個月取消會怎樣？」這在第一週是五分鐘對話，在第八週是三天的 refactor。
第 3 週：設計與架構鎖定
第三週是一整週的設計鎖定。前 10 個頁面的 UI wireframe、最高流量使用者旅程的 Figma 可點擊 flow、命名框架/資料庫/queue/cache/託管層級的架構圖、以及一份書面的非功能性需求：頁面載入預算、預期尖峰並發數、可及性基線（2026 預設是 WCAG 2.2 AA）、資料保留政策。
非功能性需求清單是團隊長期投資不足的地方。一個沒被問過「每季可接受多少停機時間？」的客戶，會預設「零」。這個預設值會花掉專案 3 到 10 倍的託管預算。比較好的做法是把數字攤開、把 SLA 報價清楚、讓客戶自己選。
第 4–9 週：用兩週為單位的 sprint 建置
六週建置切成三個兩週 sprint，每個 sprint 結尾都有一次對著真實資料的 demo。第一個 sprint 處理身份驗證、資料模型、最高流量的 CRUD flow。第二個 sprint 處理整合（金流、Email、搜尋、檔案儲存）和 IMS 後台。第三個 sprint 處理行動 App、對外網站的細節打磨，以及報表層。
幾個防止「時間都跑哪去了？」的紀律：每次 sprint demo 都跑在「seed 過真實資料的 staging」上，不是 lorem ipsum；每個整合在下一個 sprint 開始前就 wire 到底，不是先 stub；每週結束都要有一個可部署的 Docker image。
第 10 週：硬化與效能
第十週專做那些沒紀律的專案都會跳過的活。安全檢視（OWASP Top 10、參數化查詢稽核、CSP header、速率限制、驗證流程檢視）。效能檢視（每個模板頁的 Core Web Vitals、常用查詢的索引檢視、N+1 query 大掃除）。可及性檢視（每個流程都用鍵盤走過、色彩對比稽核、螢幕閱讀器走一遍）。產出是一份有嚴重度標籤的缺陷清單，這週剩下時間工程團隊只處理 critical 和 high。
這一週的投資，在客戶第一次看到 Lighthouse 跑出 95+ 分、OWASP ZAP 掃出零高嚴重度發現的時候就回本了。這也是多數接案團隊為了「省時間」會跳過、然後在上線後用免費客服吸收掉的那一週。
第 11 週：託管、可觀測性、災難復原
託管是「產出」，不是「順便做的事」。第十一週的產出是一個有文件、可重現的 production 環境：Nginx 反代 PHP-FPM 或 Node tier、後面接 load balancer，managed MySQL 開啟 point-in-time recovery，物件儲存放檔案，可觀測性涵蓋每一頁的可用率、錯誤率、回應時間。災難復原 runbook 涵蓋資料庫宕機怎麼辦、應用回 5xx 怎麼辦、DNS 走錯怎麼辦、部署需要 rollback 怎麼辦。每一步都寫下「要跑的指令」和「值班的人是誰」。
對中小企業，兩個不顯眼但重要的選擇：用 managed database，不自己跑（為了省每月 80 美元自己維 MySQL，5 萬使用者規模下不划算）；所有對外靜態資源預設掛 CDN（2026 年 Cloudflare 是又便宜又好的入門基線）。
第 12 週：上線、交接、與維運第一個月
最後一週是上線與交接。上線分階段：第一天 soft-launch 給內部使用者；第三天邀請制 beta；第五天正式公開。每個階段都有 rollback 方案，並且根據第一週談好的錯誤率與轉換率指標，明確訂出 go/no-go。
交接是「有文件的產出」，不是「口頭走過一遍」。tag 過 1.0 release 的原始碼、部署 runbook、事件回應 runbook、架構圖、資料模型、所有憑證轉移到客戶的密碼管理器、加上一支給客戶未來雇員看的 60 分鐘錄製 walkthrough。維運合約從正式公開上線那天起算——通常是一份每月固定服務費，涵蓋安全更新、依賴升級、約定時數內的小功能調整、與事件值班。
抓走多數專案的三個考量
第一：沒被列範圍的整合。客戶會在第八週「順便」說一句「對了，訂單要進我們現有的 ERP」。第一週就把所有整合掀出來，否則它會吃掉你的時程。
第二：客戶還沒寫的內容。一個站沒有文案、圖片、法律頁面與 IMS 種子資料就不能上線。把客戶內容到位的時間也放上同一張 Gantt。
第三：上線後的維運現實。沒有人領薪水照顧的網站，六個月內一定退化。把維運合約跟建置合約同一天簽下去。客戶會在第七個月感謝你。
結果
跑完這個 12 週架構，客戶拿到的是一套運作中的 Web + IMS + App 整合系統、一個有文件的 production 環境、一本交接 binder，以及一份從上線第一天起就照顧系統的維運合約。接案團隊拿到的是準時完工的盈利專案、以及會續約的客戶。這份 playbook 上最貴的一條成本不是工程工時，是「避免重新報價」的那幾週發現期投資。2026 年，這個交易是任何中小企業在數位產品上能做的最划算投資。