iOS App 外包詢價需求整理工具
找開發者報價前,先把第一版需求寫清楚。這個工具從外包詢價規格卡中挑出最關鍵的 14 個問題,讓你逐題整理想法,再依原規格卡格式產生 TXT 初稿。所有欄位都可以不填。這份初稿只是詢價的起點,不是合約,也不是完整規格;細節仍要和開發者逐項確認。
本工具不會傳送、保存或追蹤你填寫的內容。資料只留在目前開啟的頁面中,除非你自己複製或下載;重新整理或關閉頁面就會清空。工具沒有追蹤程式,不載入外部資源,不使用瀏覽器儲存,也沒有表單送出功能。初次開啟時,瀏覽器仍會下載這個 HTML 檔;點選回到指南的連結時,也會照常開啟網頁,但這些連線都不會帶上你填寫的內容。請不要在任何欄位輸入姓名、聯絡方式、帳號、密碼、金鑰或測試帳號;這些資料請等正式簽約後,再透過安全的方式提供。
可以留白。寫不出來時,可以先寫「未決定」,不必硬填。
要解決的問題
開發者最需要知道的是這個 App 為誰而做、解決什麼問題。先把問題講清楚,功能範圍才容易收斂。
盡量具體描述一群人,例如他們的工作、處境或習慣,避免只寫「所有人」。
描述沒有這個 App 時,他們目前用什麼方法、工具或流程。
指出現有流程中最麻煩、最花時間或最容易出錯的那一步。
用一句話描述第一版上線後,怎樣才算達到目的。最好是觀察得到的結果。
功能範圍
報價高低主要取決於功能範圍。第一版只放非做不可的功能,其他的明確標成「之後再做」或「不做」,雙方對範圍的認知才不會有落差。
少了這個功能,App 就沒有存在的意義。用使用者能完成的事來描述。
依重要性往下排。沒有的話可以留白。
如果第一版的必要功能超過三項,建議重新檢查是否每一項都非做不可。
想要、但第一版可以先不做的功能。寫下來可以讓開發者預留擴充空間,也能避免它被默默算進報價。
寫下這一版確定不做的功能,可以減少日後對範圍的爭議。
資料與串接
串接外部服務和處理敏感資料,會大幅影響開發難度、送審要求和後續費用,最好在詢價時就讓對方知道。
列出你知道需要串接的服務類型,例如 AI 模型、地圖、金流、日曆等。不確定時寫「未決定」即可。這裡請只寫服務名稱,不要貼上任何金鑰。
如果 App 會接觸這類資料,隱私揭露、送審和資安要求都會更嚴格。沒有的話可以寫「無」。
時程與預算
誠實寫出時程和預算,開發者才能提出可行的方案,而不是只給一個數字。
寫下理想的上線時間。請記得預留 App Store 審核和可能被退件後修改的時間。
說明日期是否有彈性,以及背後的原因,例如配合活動、檔期或其他外部限制。
寫一個範圍比只寫上限更好溝通。還不確定時,可以先寫「未決定」。
清空所有欄位
確定要清空全部 14 個欄位嗎?清空後無法復原。
這個工具是單一 HTML 檔案,存到自己的電腦後,離線也能使用。工具只收錄原規格卡中的 14 個欄位,原卡還有其他欄位沒有列入;下載 TXT 後,可以離線自行補齊。沒有填寫的欄位會依原卡格式輸出,其中有些欄位原本就會顯示「未決定」,不一定是空白。
預覽規格卡
iOS App 外包詢價規格卡 版本:2026-10-01|學域 Realms 編輯團隊 說明頁:https://course.ray-realms.com/blog/ios-app-diy-course-or-outsource 使用方式 - 先自己填一遍。答不出來的欄位寫「未決定」,不要硬填。 - 把同一份檔案交給每一位詢價對象,請對方逐項回覆。 - 本卡不是合約。正式委託前,請把範圍、驗收、帳號、原始碼和維護寫進書面約定。 一、基本資訊 委託人/公司: 聯絡方式: App 暫定名稱: 填寫日期: 二、要解決的問題 目標使用者是誰: 他們現在怎麼處理這件事: 這個 App 讓他們省掉哪一步: 第一版成功的樣子(一句話): 三、平台與裝置 [ ] 只要 iPhone [ ] iPhone + iPad [ ] iOS + Android [ ] 另外需要網頁後台 [ ] 未決定 最低支援的 iOS 版本:未決定 原生開發或跨平台:未決定 四、功能清單 第一版必要(依重要性排序) 1. 2. 3. 之後再做 1. 2. 明確不做 1. 五、帳號、資料與後端 使用者需要登入嗎:未決定 登入方式: 資料存放位置:[ ] 只存在手機 [ ] 雲端同步 [ ] 未決定 需要管理後台嗎:未決定 有付款功能嗎:[ ] 沒有 [ ] App 內購買/訂閱 [ ] 實體商品或服務付款 [ ] 未決定 要串接的 AI 或其他 API: 會處理的敏感資料(健康、財務、位置、兒童等): 資料保存多久、使用者刪除帳號後怎麼處理: 六、帳號與所有權(建議都放在委託人名下) Apple Developer Program 帳號名義:[ ] 個人 [ ] 組織 [ ] 尚未申請 組織的 D-U-N-S 編號狀態:[ ] 已有 [ ] 申請中 [ ] 政府實體(依 Apple 規定可能不需要) [ ] 未決定 開發者需要的 App Store Connect 角色: (個人會員只能給對方 App Store Connect 存取權,對方不是 program 團隊成員;組織會員才能把對方加入團隊。本卡不需要、也請勿填寫 Apple 帳號密碼或任何金鑰。) 原始碼存放位置: 後端/雲端服務帳號名義: AI API 帳號名義與付款方式: 網域、寄信、推播等服務的帳號名義: 七、驗收情境(每個必要功能至少寫一條) 格式:情境|操作步驟|預期結果|驗收結果|驗收日期 1. |||| 2. |||| 3. |||| 4. |||| 5. |||| 驗收用的裝置與 iOS 版本: 八、上架與送審 誰準備商店截圖與文案: 誰撰寫隱私權政策?網址放在哪裡: 誰填寫 App Store Connect 的隱私揭露: 審核用的測試帳號: 被退件時的修改是否包含在報價內: 九、時程與預算 希望上線日期: 這個日期能不能延後?原因: 預算區間: 付款方式(分期、依里程碑): 十、交付物 [ ] 原始碼 [ ] 建置與部署說明 [ ] 第三方服務與 SDK 清單 [ ] 帳號與權限清單 [ ] 驗收紀錄 [ ] 其他: 十一、交付後維護 保固期間: 保固範圍: 回覆時間: iOS 大版本更新時的處理方式與計價: Apple 最低 SDK 要求變更時的處理方式: 第三方服務的月費由誰支付: 十二、請開發者回覆 1. 你們用原生還是跨平台開發?用哪個版本的 Xcode? 2. 上面每一項功能,哪些包含在報價內、哪些要另外計費? 3. 報價包含幾輪修改?怎樣算一輪? 4. 會用到哪些第三方 SDK?各自收集什麼資料? 5. API 金鑰等機密資訊存放在哪裡?會不會被寫進 App 裡? 6. 每次交付都會提供原始碼,以及能重現的建置方式嗎? 7. 你們會怎麼示範驗收情境?沒通過時怎麼處理? 8. 送審被退件時,誰負責修改和回覆? 9. 交付後的保固和維護怎麼計價? 10. 有可以查證的過往作品嗎(例如 App Store 連結)? 11. 依我的會員身分(個人或組織),你們需要什麼權限?簽署和上傳怎麼分工? 十三、報價比對(每家一欄,自行填寫) 項目|A|B|C 總價||| 包含的功能||| 包含後端||| 包含上架送審||| 修改輪數||| 保固期||| 原始碼交付||| 上架帳號名義||| 預計時程||| 備註: