第一段：算幾個平台
同一個 app，只做一個平台、做兩個平台、或用跨平台方案共用一套程式碼，是三種工作量。報價單如果只寫「App 開發」，你沒辦法知道它含幾個平台，而這一段本身就能差一倍。
要問的是具體的：報價含哪幾個平台、跨平台方案是哪一種取捨、上架送審算不算在裡面。最後這一項最常被漏，而它是實際會吃掉工時的環節。
- 平台數量要寫進報價單，不能只寫「App 開發」
- 跨平台不等於成本減半，共用程式碼仍有各平台的適配工作
- 上架送審與被退件後的修正，要事先說清楚算誰的
第二段：後端到哪裡為止
帳號系統、推播、金流、以及要不要接既有系統——這四項任一個從「不含」變成「含」，工作量都會明顯跳一階。它們在需求討論時最常被口頭帶過（「這個應該不難吧」），然後在開發中變成追加。
尤其是接既有系統這一項：既有系統的文件完整度決定了這段是兩週還是兩個月，而那件事在報價階段通常還沒人查過。
- 帳號、推播、金流、既有系統整合，四項要逐項確認含或不含
- 接既有系統的工時取決於對方文件完整度，報價前值得先花時間確認
- 「應該不難」是報價風險最高的一句話
第三段：人月怎麼估出來的
前兩段是範圍問題，講清楚就沒有歧義。第三段不一樣：同一份功能清單，不同團隊估出來的人月可以差一倍，而且兩邊都可能是誠實的判斷。
費率那一側反而是公開的。根據中華民國資訊軟體服務商業同業公會的 115 年資訊服務委外經費估算原則，「軟體開發及程式設計師」的人月報價是 181,502 元、207,486 元、235,232 元，依三個級別分。費率公開、職類公開，所以總額的變數集中在人月數——那才是該追問的地方。
- 費率有公開對照表，人月沒有——差距主要出在人月
- 問「哪幾個功能最吃工時」，比問「能不能再便宜一點」有用
- 問「砍掉這個功能會少幾個人月」，可以驗證對方是不是真的拆過
把三段問完，剩下的才是真價差
三段對齊之後，如果報價還是有差，那才是真正的價差——可能來自費率級別，也可能來自對複雜度的判斷不同。這時候你比的是同一件東西，決策才成立。
同一套拆法也適用於網站報價，見網頁設計費用為什麼問不出答案；估算原則的完整用法見資訊委外經費估算原則怎麼用。