很多 App 專案在還沒有第一個使用者之前，就已經開始想第二年的問題。
要不要先做會員等級？要不要支援多國語言？資料庫以後如果有一百萬人怎麼辦？通知系統要不要拆成微服務？Android 和 iOS 要不要同步上？後台是不是要一次做完整？
這些問題不是永遠不重要。
問題是，它們很可能不是現在最重要。
如果最核心的假設是「使用者根本沒有這個需求」，那麼你把資料庫設計到可以承受一千萬人，也不會讓產品更接近成功。
新 App 最需要管理的，不只是開發速度，而是驗證順序。
第一步：先找出「如果錯了，整個 App 就不成立」的假設
Eric Ries 在《The Lean Startup》中把創業視為一連串需要被驗證的假設。
其中有些假設錯了，還能調整；有些假設一旦錯，產品就失去成立基礎。
例如你想做一個幫自由工作者自動整理客戶需求的 App。
最危險的假設可能不是「使用者喜歡藍色還是紫色」，而是：
自由工作者真的覺得整理需求很痛苦嗎？
他們現在有沒有其他方法可以處理？
這個痛點嚴重到值得改變既有習慣嗎？
他們願不願意把客戶資料交給一個新工具？
如果這些假設都還沒有證據，先做完整 App 很容易變成昂貴的猜測。
MVP 不是「功能很少的正式產品」，而是最小的學習工具
Minimum Viable Product 常被翻成最小可行產品，但很多人把它理解成「先做一個很陽春的版本」。
這種理解容易走偏。
MVP 真正要回答的是：要驗證目前最重要的假設，最少需要做什麼？
有時答案根本不是 App。
如果你想驗證是否有人願意使用一個複雜的自動化功能，可以先用人工方式替少量客戶完成，觀察他們是否真的願意持續使用。
如果你想驗證需求，可以先做一個清楚的介紹頁與等待名單，看目標客群是否真的願意留下聯絡方式。
如果你想驗證操作流程，可以先做高擬真原型，讓使用者完成任務，而不是先寫後端。
真正的 MVP，是為了學習而存在。
它不等於粗製濫造，也不代表上線後就不管品質。
Build-Measure-Learn 的重點，是先決定要學什麼
Build-Measure-Learn 常被誤解成「先做、再看數據」。
比較好的方式其實是倒過來規劃。
先問：這一輪最重要的是學到什麼？
再問：什麼證據能讓我判斷這個假設成立或不成立？
最後才問：要取得這個證據，最少要做什麼？
例如你假設「講師願意每週用 App 整理一次學員問題」。
那真正需要的證據不是「十個人說聽起來不錯」，而是十個人裡有多少真的連續幾週使用。
行為證據通常比意見更有價值。
第二步：需求有訊號後，再測核心體驗，不要急著寫正式程式
有需求，不代表你設計的流程就好用。
這時 Design Sprint 很有價值。
Google 的 Design Sprint 方法強調，用短時間理解問題、產生方案、做原型，再讓真實使用者測試。
原型的目的不是展示畫面漂不漂亮，而是測最危險的體驗問題。
例如：
第一次打開 App 的人，知道下一步要做什麼嗎？
他能不能在沒有說明的情況下完成核心任務？
他會在哪一步停住？
他以為某個按鈕會做什麼？
如果原型階段就發現流程讓人困惑，現在修一張畫面很便宜；正式程式寫完後再重做，成本就高很多。
第一版最該測的，是「第一個十分鐘」
新 App 常常花很多時間設計進階功能，卻忽略使用者第一次進來的體驗。
但對一個還沒有既有信任的新產品來說，前十分鐘非常重要。
使用者能不能理解這個 App 是做什麼的？
能不能完成第一個有價值的動作？
有沒有在還沒得到價值前，就被要求建立太多資料、設定太多選項？
如果使用者連第一個核心任務都完成不了，後面的進階功能再完整也沒有用。
所以第一版設計，應該先把最重要的「價值路徑」做順，而不是先把所有頁面補齊。
第三步：原型通過後，才開始決定哪些架構值得先做好
「不要過度設計」不代表架構隨便寫。
真正需要區分的是：什麼是現在就會影響未來選擇權的決定，什麼是以後再改也很便宜的決定。
例如框架樣式、某個次要頁面的 UI，通常比較容易替換。
但核心商業規則如果直接和資料庫、第三方 API、付款服務綁死，未來每一次替換都會變得昂貴。
Clean Architecture 提醒我們，核心商業規則應該盡量獨立於外層框架與資料庫。
不是因為第一版就要做成大型企業架構，而是讓最重要的規則不要被最容易變動的技術綁住。
可以延伸閱讀 Clean Architecture：為什麼商業邏輯不該被框架與資料庫綁死。
第一版應該保留邊界，但不需要堆滿抽象層
新 App 另一個極端，是一開始就按照「未來會很大」的想像做架構。
每個功能都有 Interface、Factory、Adapter、Service、Repository，再拆成很多服務。
最後還沒有第一個付費使用者，團隊已經先維護大量抽象。
好的第一版架構應該保留重要邊界，但不必追求層數。
例如：
付款服務可能會換，所以包一層自己的介面很合理。
核心商業規則需要獨立測試，所以不要直接寫在 Controller 裡。
但一個只在單一地方使用、短期也不太會改的小功能，不一定需要先建立五層抽象。
架構的目的，是降低未來改動成本，不是讓程式碼看起來很「企業級」。
第四步：先定義領域語言，避免功能愈做愈多、名稱愈來愈亂
Domain-Driven Design 很重要的一個觀念，是讓程式裡的名稱和業務世界說同一種語言。
如果你的 App 是做課程管理，程式裡應該出現 Course、Enrollment、Lesson、Access 等真正有業務意義的概念，而不是到處都是 DataManager、Helper、Processor。
清楚的領域語言，可以讓產品、設計與工程更容易討論同一件事。
第一版不一定需要做完整 DDD，但至少應該先把最核心的名詞講清楚。
因為名字混亂通常不是文字問題，而是團隊其實還沒有把概念想清楚。
第五步：第一版可以小，但程式碼不能因此變成一次性垃圾
MVP 常被拿來當成「反正先亂寫」的理由。
這很危險。
真正的一次性原型，如果驗證完就丟掉，確實可以用最低成本完成。
但只要決定要把它變成正式產品，就應該開始建立基本品質。
例如：
名稱看得懂。
核心函式責任清楚。
重要行為有測試。
錯誤不要被偷偷吞掉。
重複的商業規則不要散落各處。
因為最容易發生的事情，就是「這只是 MVP」最後一路活成正式產品兩三年。
第六步：先做一條真正跑得通的垂直切片
與其一次把前端全部畫完、後端全部做完，再最後整合，不如先做一條非常薄但完整的流程。
例如一個課程 App，第一條垂直切片可能是：
使用者登入 → 開啟一門課 → 完成一個單元 → 系統儲存進度 → 下次回來看得到。
這條路徑從介面一路穿過商業邏輯、資料存取到真正儲存。
完成它的好處，是很早就能發現整合問題。
如果等三週後才把各層接起來，真正的技術風險也會拖到很後面才出現。
第七步：先估算真實流量，再決定要不要做大型系統設計
新 App 很容易過早擔心規模。
「如果未來有一百萬人怎麼辦？」
這是一個合理問題，但應該先算數字。
假設第一年預計有 2,000 位日活躍使用者，每人每天做 20 次主要操作。
平均下來，每秒請求數其實很低。
這種規模通常離「一定要分散式架構、分庫分表、複雜訊息系統」還很遠。
真正好的 System Design，不是能畫最複雜的圖，而是知道目前不需要什麼。
先用簡單、可靠、容易維護的架構承受實際流量；等數據證明瓶頸出現，再針對真正限制擴充。
不要為「也許有一天」先做大量功能
第一版功能膨脹，很多時候都來自一句話：
「這個以後可能會用到。」
也許有一天需要多語系。
也許有一天需要十種登入方式。
也許有一天企業客戶會要求複雜權限。
也許有一天要支援五種方案。
這些都可能成真，但每一個「也許」都會提高今天的設計、開發、測試與維護成本。
37signals 的 Shape Up 強調固定時間、彈性範圍。
先決定這個問題值得投入多少時間，再讓功能範圍配合時間，而不是功能一直加、日期一直延。
如果你常遇到「功能愈做愈多、一直無法上線」，可以延伸閱讀 37signals 如何用少做一點，反而更快做出好產品。
第一版最常太早做的八件事
第一，過早做多平台。 如果一個平台就能驗證核心需求，不一定要同時做 iOS、Android、Web。
第二，過早做微服務。 還沒有清楚模組邊界時，拆微服務只是把複雜度搬到網路上。
第三，過早做高度客製化。 每一個選項都代表更多 UI、測試與支援成本。
第四，過早做完整後台。 早期很多管理工作可以先人工處理，等流程穩定再自動化。
第五，過早做精緻動畫。 核心流程尚未驗證前，動效不是最高風險。
第六，過早做大量報表。 先確認使用者真的需要哪些決策資訊。
第七，過早為極端流量優化。 沒有數據支持的擴充設計，很容易只是增加維護負擔。
第八，過早建立完整權限矩陣。 如果第一批客戶根本不需要複雜角色，就先不要把它做成大型企業系統。
那哪些事情反而不能太晚做？
「不要太早做」不等於什麼都延後。
有幾件事值得早點確認。
需求證據。 沒有這個，後面所有投入都可能浪費。
核心流程。 第一個價值時刻一定要被測試。
資料與隱私風險。 如果涉及敏感資料，不能等上線後才補。
重要商業規則。 付款、權限、訂閱、存取等核心邏輯，應該有清楚邊界與測試。
可逆性。 第三方服務、付款商、AI 供應商等可能更換的地方，應盡量避免把整個系統綁死。
真正好的第一版，是把「難以逆轉的決定」想清楚，把「容易之後再改的東西」延後。
發佈第一版之後，真正的產品工作才開始
很多團隊把 Launch 當成終點。
但第一版上線後，你才第一次拿到真實世界的使用資料。
誰真的使用？
哪一步一直失敗？
哪些功能根本沒有人碰？
哪些人會留下？
他們為什麼留下？
這時應該進入持續探索，而不是立刻照原本 Roadmap 繼續堆功能。
可以延伸閱讀 Continuous Discovery Habits：產品團隊為什麼要每週接觸客戶，建立固定的客戶接觸與假設測試節奏。
一個比較安全的 App 第一版順序
如果把整個流程簡化，可以用這個順序思考：
先驗證問題：這個需求真的存在嗎？
再驗證行為：使用者願意採取什麼實際行動？
再測核心流程：原型能不能讓人自己完成主要任務？
再做最小正式版本：保留重要邊界，但不要過度架構。
再做一條完整垂直切片：提早驗證技術整合。
再估算容量：用數字決定真正需要的規模。
再固定發佈節奏：用範圍取捨保護上線時間。
最後持續學習：用真實使用資料決定下一個版本。
第一版真正要保護的，是學習速度
做新 App 最容易掉進兩個極端。
一個是什麼都先亂做，結果產品一有使用者就必須重寫。
另一個是一開始就把未來五年的問題全部設計完，結果半年後還沒有東西能讓客戶使用。
比較好的做法在中間。
對需求與核心流程保持高度懷疑，先用低成本方法驗證。
一旦決定正式打造，就把真正重要的邊界與商業規則做好。
對尚未發生的規模、功能與複雜情境保持節制。
第一版不是要證明你能做多少。
它真正要證明的是：這個產品值得繼續做，而且你已經找到下一步該往哪裡走。
常見問題
MVP 是不是就是功能很少、品質比較差的 App？
不是。MVP 的重點是用最小成本取得關鍵學習。原型或實驗可以很簡單，但如果決定成為正式產品，核心品質、資料安全與重要商業規則仍然不能隨便。
新 App 一開始要不要先做完整架構？
不需要把未來所有規模都設計完，但重要商業規則、外部依賴與容易變動的技術邊界值得提早隔離。架構應該保留選擇權，而不是堆疊抽象。
什麼時候才需要考慮微服務？
當實際規模、團隊邊界、部署需求或瓶頸已經證明單體架構成為限制時，再評估比較合理。第一版在沒有證據的情況下先拆微服務，通常只會增加複雜度。
第一版應該同時做 iOS 和 Android 嗎？
不一定。如果單一平台已足以驗證核心需求與使用流程，先集中資源通常更有效。等價值被證明，再擴充平台會更有依據。
App 上線後最重要的是加更多功能嗎？
通常不是。上線後更重要的是觀察真實使用行為、留存、核心任務完成率與客戶回饋，確認下一個最值得解決的問題，再決定功能優先順序。
參考資料
Eric Ries. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses.
Eric Ries. “MVPs and Excellence.” The Lean Startup.
Jake Knapp, John Zeratsky, and Braden Kowitz. Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days.
Google. “Design Sprint Kit.”
Robert C. Martin. Clean Architecture: A Craftsman’s Guide to Software Structure and Design.
Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software.
David Thomas and Andrew Hunt. The Pragmatic Programmer: Your Journey to Mastery.
Martin Kleppmann. Designing Data-Intensive Applications.
Ryan Singer. Shape Up: Stop Running in Circles and Ship Work that Matters.
John Ousterhout. A Philosophy of Software Design, Second Edition.