客製系統開發與電商建置，
包含什麼、不包含什麼

1. 01

   釐清

   把要解決的問題與範圍寫成一份可以簽的東西：現在實際怎麼運作、要改掉哪幾件事、這一次不做哪幾件事。

   需要你這邊有人能回答「現在實際上是怎麼做的」。

   1–2 週
2. 02

   建模

   先畫資料表：有哪些欄位、彼此怎麼關聯、誰可以寫。介面與流程在這一階段一起定案。

   需要你確認欄位定義與例外情況：退貨、換貨、作廢、折讓。

   1–2 週
3. 03

   開發

   兩週一段，每一段結束都給你一個可以點的預覽網址，不是文字進度報告。

   需要你每兩週看一次預覽並給回饋。

   4–10 週
4. 04

   上線

   資料搬遷、金流與電子發票在正式環境跑端對端測試、寫好切換 runbook 與回滾步驟，然後才切。

   需要你提供正式金鑰與帳號，並安排切換當天的人力。

   1–2 週
5. 05

   維運

   交付之後陪跑：修正、調整、教育訓練。三個月後可以續維護，也可以整包交給你們自己的工程師。

   回報問題時附上發生時間與畫面，就能少一輪來回。

   三個月起

時程是依這五個階段推估的常見區間，視範圍而定。官網與電商建置多半落在 6 到 10 週，客製系統多半落在 3 到 6 個月；確定的時程表在釐清階段結束時才給，不在第一次會議就報數字。

• Next.js · React · TypeScript內容直接進 HTML，Google 與 AI 抓取器不用等 JavaScript 跑完才看得到字；型別在編譯期就擋掉一半的欄位錯誤，剩下的才輪到測試。
• Supabase · PostgreSQL資料表、權限、檔案、排程在同一個地方。權限寫在資料庫這一層（RLS），前端再怎麼改都繞不過去 —— 這跟「把檢查寫在畫面上」是兩種安全等級。
• Vercel每一次改動都有一個獨立的預覽網址，你先看過再上線；出事回滾是一個按鈕，不是重新部署一次。
• 綠界 ECPay · PayUni 統一金流台灣買方習慣的付款方式 —— 信用卡、ATM、超商代碼、行動支付 —— 都在這兩家。真正會出事的是回呼的冪等處理：同一筆通知送兩次不能入帳兩次，這一段我們踩過也修過。
• 鯨躍電子發票開立、作廢、折讓走 API，不用有人每天登入平台手開。字軌與配號設定第一次上線時我們陪你走一次，之後每期自己續。
• LINE Login台灣的登入現實。少一組要記的帳號密碼，註冊完成率就不一樣；而且之後要發通知時，人已經在那個管道上了。
• Web Push · Google Calendar API · pg_cron該提醒的事情自己會跑，不靠人記得。排程跑在資料庫端，不依賴某一台機器有沒有開著。

開始之前要準備什麼？

三樣東西：現在實際怎麼運作（Excel、紙本、LINE 群組都算）、你最想改掉的三件事、以及要串的第三方帳號有哪些（金流、電子發票、LINE、網域）。沒有規格書也可以開始，釐清階段做的就是這件事。

一個案子大概要多久？

官網與電商建置多半落在 6 到 10 週；客製系統看範圍，常見是 3 到 6 個月。時程取決於範圍大小與你這邊回覆的速度。我們在釐清階段結束時才給確定的時程表，不在第一次會議就報一個數字。

上線之後誰維護？

交付後三個月陪跑，包含修正與調整。三個月之後可以續維護，也可以把原始碼與資料庫整包交給你們自己的工程師 —— 交接文件與資料表說明在上線階段就已經給了，不會被綁住。

可以只做一部分嗎？

可以。常見的是先做資料模型與後台，前台之後再補；或者只把金流與電子發票串接到你現有的站上。但是「只做畫面、不碰資料」我們不接，那通常只是把問題往後推半年。

現有的系統能不能接？

看它願不願意把資料放出來。有 API 就直接串；只能匯出 CSV 就做定期匯入；完全封閉的雲端服務要先評估風險再決定要不要搬。我們做過 7,181 筆資料的系統搬遷，零遺失。

一定要到公司談嗎？

不用。多數案子用線上會議進行，全台灣都可以跑。需要看現場的（例如門市的 POS 實際上是怎麼被按的）我們就到現場。