服務

APP 和後台可以拆給兩家外包做嗎?用「拆包風險分數」判斷:8 項滿分 16 分,9 分以上交給同一家或指定總包,拆包常多出 15–25% 的溝通與整合成本

2026.11.08 · 23 次瀏覽
APP 和後台可以拆給兩家外包做嗎?用「拆包風險分數」判斷:8 項滿分 16 分,9 分以上交給同一家或指定總包,拆包常多出 15–25% 的溝通與整合成本
“

很多老闆覺得把 APP 給 A 家、後台給 B 家,可以各挑最便宜、最擅長的。整理拆包的 3 個迷思、可重複使用的拆包風險分數、3 種情境的不同結論、拆包的隱藏成本、評估外包夥伴的 KPI 計分卡、6 週啟動遊戲書與決策清單。 ”

分享:

直接答案:可以拆,但多數中小企業不該拆。用「拆包風險分數」8 項、每項 0–2 分評估,9 分以上就交給同一家或指定一家當總包;拆給兩家常多出 15–25% 的溝通與整合成本,出問題時還會互相推責任。

客戶真實問題:兩份報價加起來比較便宜,結果多付了 3 個月

一家 25 人的連鎖健身品牌要做會員 APP 和預約後台。A 家 APP 報價 NT$45 萬,B 家後台報價 NT$38 萬,加起來比單一廠商 NT$95 萬便宜 12 萬。開工後 API 規格改了 6 版,兩邊互等,上線延後 3 個月;出現扣款錯誤時,兩家都說是對方的問題。最後另花 NT$8 萬請顧問做整合測試,省下的錢幾乎吐回去。

業界迷思打破

拆包省的是報價單上的數字,不是專案總成本。

  • 迷思 1:各找最擅長的,品質一定比較好。真相:系統品質大多壞在介面與資料定義,兩家各自做得很好,接起來仍可能錯。
  • 迷思 2:有 API 文件就能分工。真相:文件只寫「欄位」,沒寫「流程」。退款、取消、離線重送這些例外,要兩家一起定才會一致。
  • 迷思 3:拆開比較不會被綁住。真相:避免被綁靠的是拿到原始碼、文件與主機權限。

核心框架:拆包風險分數

8 項各打 0–2 分,總分越高越不該拆。

項目0 分2 分
前後端互動頻率只同步少量資料每個畫面都要即時呼叫
金流與扣款沒有APP 內付款、退款、訂閱
需求確定度規格已凍結邊做邊改
公司內有技術窗口有工程背景 PM完全沒有
上線時程壓力6 個月以上3 個月內
兩家是否合作過合作過多次互不認識
API 規格由誰定已有既有後台 API雙方一起從零定
上線後維護同一家負責各修各的

0–5 分可以拆;6–8 分可拆但要指定總包;9 分以上交給同一家。

三類典型情境對照

結論依規模與成熟度不同。

  • 情境 A|已有穩定後台,只加 APP(4 分):可拆,APP 廠商照既有 API 串接。
  • 情境 B|電商官網+獨立行銷活動頁(6 分):可拆,但指定官網廠商當總包,負責會員與訂單資料的規格。
  • 情境 C|從零做會員 APP+預約扣款後台(12 分):交給同一家。金流、預約與通知高度互動,拆開幾乎一定延期。

隱藏成本完整清單

多出的成本不會出現在報價裡。

  • 介面協調會議:每週 1–2 小時 × 3 方,3 個月約 40–70 小時。
  • API 規格反覆修改:常占兩家總工時 10–15%。
  • 整合測試:需另找第三方或自己做,約 NT$5–15 萬。
  • 責任釐清:每次故障平均多花 1–3 天判斷是誰的問題。
  • 兩份維護合約:月費加總常比單一廠商高 2–4 成。

評估外包夥伴的 KPI 計分卡

不論拆不拆,用 8 個維度打分,每項 1–5 分。

  • 是否主動提出 API 規格文件與版本管理
  • 是否有整合測試計畫與測試環境
  • 錯誤監控工具(如 Sentry)
  • 例外流程(退款、取消、離線)的設計能力
  • 週報與進度透明度
  • 原始碼與文件交付條款
  • 上線後回應時效(SLA)
  • 變更需求的計價方式

ScriptWalker 的對應方案 + 不適合情境

ScriptWalker(台灣 Laravel/Flutter 客製化開發工作室)同時做 Laravel 後台與 Flutter APP,適合「一家負責到底」的專案(Project 模式),也能在客戶已有 APP 廠商時擔任後台與 API 的總包。上線後可轉為月費維護(Retainer)。系統類專案 NT$80,000 起、APP 專案 NT$150,000 起。

我們不適合:

  • 只要一家便宜外包做 APP 畫面,不在意後台與資料結構。
  • 已有大型內部 IT 團隊,只需要短期派遣工程師。
  • 需要原生深度硬體功能且預算低於 NT$50 萬。

啟動期遊戲書:如果還是要拆,前 6 週這樣做

決定拆包時,先把規則定死再開工。

  • 第 1 週:指定總包,負責 API 規格、測試環境與最終整合。
  • 第 2–3 週:用 OpenAPI 寫完第一版 API 規格,雙方簽認。
  • 第 4 週:建好共用測試環境與假資料,後台先做假 API 讓 APP 開工。
  • 第 5–6 週:每週三方站會,只處理規格差異清單。

決策清單

  • ☐ 拆包風險分數低於 9 分?
  • ☐ 已經有穩定運作的後台 API?
  • ☐ 公司內有能看懂 API 文件的窗口?
  • ☐ 有指定一家負責整合?
  • ☐ 兩家都同意用同一份 OpenAPI 規格?
  • ☐ 有共用測試環境?
  • ☐ 合約寫明介面錯誤的責任歸屬?
  • ☐ 預算有留 15–25% 的整合成本?
  • ☐ 上線時程超過 4 個月?

常見問題 FAQ

APP 和後台給不同外包做會比較便宜嗎?

報價通常較便宜,總成本不一定。拆包常多出 15–25% 的溝通與整合成本,還要另付整合測試與兩份維護費。

什麼情況適合拆包?

已有穩定後台 API、只加 APP 或活動頁時適合。前後端互動少、規格已凍結、公司內有技術窗口,拆包風險就低。

拆包的話誰負責整合?

一定要指定一家當總包。總包負責 API 規格、測試環境與最終整合,合約寫明介面錯誤由誰處理。

行動呼籲

手上有兩份報價、正在考慮拆包嗎?把報價與需求傳給我們,我們免費幫你算一次拆包風險分數,告訴你該拆、該指定總包,還是交給一家。

分享: