做一個手機應用程式要多少錢

1. 為什麼要付兩次

這是主導整個預算的事實，也是最常在要過第一份報價之後才被發現的事實。

• 兩個系統，兩個世界。iOS 和 Android 既不用同一種語言，也沒有同樣的顯示慣例，更沒有同樣的權限規則。歷史上這意味著兩次完整開發，也就是大約兩倍的工作量。
• 共用的技術縮小了差距，但沒有抹掉它。寫一套共用的底層如今是常態，但精細調校、測試和各平台的特殊之處，仍然要做兩遍。請算一筆實實在在的加價，而不是翻倍。
• 要讓兩家商店滿意。每一家都有自己的發布規則、要按正確尺寸做的圖片、要翻譯的文案，以及要通過的審核。這本身就是一項獨立於開發的行政工作。
• 是一批裝置，而不是一台裝置。螢幕尺寸差別很大，舊版本的系統也還在用。網頁用一張樣式表就能解決的事，在這裡需要在多種組態上測試。

在同等規模下，應用程式因此在結構上比網站貴。真正的問題不是怎樣少付，而是這個應用程式是否必要——那是第5節，值得在索取報價之前先讀。

2. 逐項算出一次開發

和網站一樣，不存在任何參考價目。以下是需要分開估價的項目：把它們揉成一行的報價單，和任何其他報價單都無法比較。

• 畫面。數一數，並把展示用的和輸入用的分開：一個表單，連同它的錯誤和邊界情況，要花上查閱型畫面的好幾倍。
• 使用者帳號。註冊、登入、忘記密碼、刪除帳號——最後這一項，只要有註冊，商店就會要求。這一塊幾乎總是被低估。
• 伺服器與資料。只顯示固定內容的應用程式很便宜。一旦它要記錄任何東西，就需要資料庫、一個管理它的介面，以及備份。這往往是報價單上的第一項。
• 通知。技術上簡單，調校起來卻費錢：要申請的權限、兩個系統上不同的行為，還要寫一套業務上的判斷來決定發什麼、什麼時候發。
• 應用程式內的付款。如果涉及購買，商店會強制使用自己的機制並抽取佣金。它既是一項開發，也是你營業額的一部分。
• 在真機上的驗收。不可讓步的一步，也是緊繃的報價裡第一個被砍掉的項目——其代價會以發布後的修復來償還，而且按加急的價錢。

3. 每年都在跑的花費

被忽視的網站還在線上。被忽視的應用程式會變得不能用，然後消失。這是本質的差別，而且是一個和錢有關的差別。

• 開發者帳號的費用。發布需要在每家商店都有帳號：Apple 那邊是年費訂閱，Google 那邊是一次性費用。金額不大，但 Apple 的訂閱沒續，應用程式就會下架。
• 被強加的更新。每年，iOS 與 Android 的新版本都會挪動規則，而商店要求使用較新的工具編譯才肯接受更新。所以即使應用程式一點沒改，也得動手。
• 伺服器。主機代管、資料庫、備份：一筆隨使用量成長的月度花費。
• 修復。應用程式的當機不像一個壞掉的頁面那樣顯眼：它出現在商店的評價裡，而且會在那裡留上好幾個月。
• 盯著評價。沒有人管它們，而它們是未來的使用者最先讀到的東西。

簽約之前，請按三年為這些項目編列預算。交付時沒有後續預算的應用程式，是一個終將被商店下架的應用程式——有時還沒派上用場就下架了。

4. 商店的代價：被退件

這是所有報價單裡都沒有的一項，而它真實存在：發布不是送件，而是審核。兩家商店都會審讀應用程式，並且常以與開發無關的理由退件——隱私權政策不完整、找不到帳號刪除入口、測試帳號無法登入、權限說明被判定不充分、與某個沒有自身價值的網站過於相似。

每一次退件都會奪走兩樣東西。時間：一次修改、一次重新送件、又一段等待。還有日期：如果上線時間已經對外公布過，它就會往後挪。在這一點上沒有留餘裕的專案，最後會因為一個行政上的理由而付加急的錢。

所以請向任何廠商問清楚：誰負責發布，誰接手被退件的情況。這個回答值得寫進報價單一行。

5. 付錢之前該問自己的那個問題

許多應用程式本來就不該開發，預算花在別處會更好。三個問題能誠實地作出判斷。

• 使用是反覆的嗎？人們裝一個應用程式，是為了那些經常要打開的事——下單、追蹤、打卡、累積回頭客。若只是偶爾看一眼，手機上的網站做得更好，也不必去爭取一次安裝。
• 你需要裝置本身嗎？通知、相機、定位、無網路下運作、條碼：如果這些都用不上，應用程式帶不來網頁做不到的任何東西。
• 誰會去裝？這是讓最多專案沉沒的一點。拿到一次安裝，比拿到一次造訪難得多。如果沒有一群已經黏住的人——熟客、會員、第一線的班組——那麼無論品質如何，應用程式都會是空的。

如果這三個答案都不乾脆，那就先做網站：關於做一個網站要多少錢的那一頁詳細說明了這條路。等使用真的出現了，應用程式自然會來。

6. 為之後付錢，而不是為發布付錢

如果花費集中在上線之後，那麼該買的就不是一次開發，而是一種能延續下去的存在。

在 nullbot，應用程式和網站一樣，是用對話描述出來的。在任何發布之前，你都能看它在 iOS 和 Android 模擬器裡跑起來——可以動手操作，也可以擷取畫面。它可以有自己的資料庫，會經過一輪驗收，會為每個目標產生安裝檔，而向 App Store 與 Google Play 的發布也在同一個地方操控，每家商店的狀態就擺在眼前。

這仍然不是我們賣的東西。我們賣的是第二年：留下來的那支智慧體團隊。它準備商店要求的更新、接手被退件的審核、修好會當機的地方、維護商品資訊及其翻譯、盯著評價。應用程式不必等一筆不會到來的維護預算——那就是團隊的日常工作。

花費不再是一個要出資、之後又要再出資的專案。它變成按月的訂閱，而發布也不再是終點線。

7. 第1週、第3個月、第2年

分出高下的三個時點——而且和網站的情況不同，因為商店會把自己的時程強加過來。

• 第1週。應用程式已在兩家商店發布，商品資訊填好了，審核用的測試帳號可以用。一個稱職的廠商做得到這一步。
• 第3個月。三則抱怨指向同一個畫面，一則兩星評價排在最前，系統出了新版本。問題變成了：是誰發布了那個修復？一個交付後就沒有後續的專案，在這裡已經在流失使用者了。
• 第2年。兩家商店都要求使用較新的工具編譯，否則拒絕任何更新。不加處理的話，應用程式在已經安裝的人那裡還在，但任何地方都裝不上了，最後連啟動都不行。重做的預算就是在這時冒出來的——而且會因為同樣的理由再次冒出來。

8. 界限，坦白說

• 高度專門的應用程式仍然是客製化開發。進階影像處理、透過藍牙連接的硬體、精細地圖、遊戲：這些都是專門的領域，需要傳統的開發預算。
• 商店的審核無法保證。沒有任何廠商能承諾通過，也不能承諾期限。能承諾的是：一直把這件事接著做下去，直到通過為止。
• 應用程式不會自己造出使用者。如果沒有人安裝，任何團隊都改變不了。請重讀第5節：那是整個專案裡最省錢的決定。
• 會讓公司承擔義務的事，都要經過一次核准。上架銷售、變動價格、向全體使用者群發訊息，在發出之前都會先呈給你。

9. 常見問題

延伸閱讀

接著讀：應用程式是怎樣一步步做出來的、做一個網站要多少錢，或雇一個人要多少錢。