這週實際把一個建構專案透過全部三種方式推上線，而不只是紙上談兵，所以這篇是實測紀錄——我做了什麼、哪裡出了問題、如果重來一次我會跳過哪些步驟。
第一天，上午——一鍵子網域
從最快的選項開始：點下發布，就取得了 yourname.buildmidas.com，不需要設定 DNS、不需要建立帳號、也不用花錢。大概四秒鐘就搞定了。這適合您只是想知道有沒有人對這個點子有興趣的時候——分享連結、觀察反應、快速迭代。我原本以為一旦應用程式需要真正的後端功能——帳號系統、資料庫、WebSocket 多人連線層——就會卡關，結果沒有，這些也都已經託管並管理好了。我這邊完全不用設定。第一天，成果不錯。
第一天，下午——試著弄壞 SFTP 部署
這部分是我最緊張的。一旦產品超出子網域的範疇、需要自己的網域時，就可以直接從建構頁面透過 SFTP 部署。我特意指向一台已經有網站根目錄、裡面放著舊檔案的伺服器，半預期它會直接覆蓋掉。結果部署智慧代理先檢查了伺服器、選定了策略——而且這點很關鍵——在動任何東西之前，先把原本既有的網站根目錄備份了下來。之後每次部署的版本也都會保留，回復只要點一下即可。所以當我二十分鐘後刻意推送一個壞掉的版本來測試時，回復所花的時間大概和發現版本壞掉所花的時間差不多。我在 無所畏懼地迭代 這篇文章裡寫了更多為什麼這件事很重要——簡單說，版本歷史讓部署從一個令人屏息的時刻變成一件無足輕重的小事。
下次我會跳過的部分：我花了二十分鐘想用一個很怪的巢狀子目錄結構去唬弄它，後來才想起整件事的重點就在於這是您的伺服器、您的網域、您的檔案——這個工具只是個小心謹慎的搬運工，不是把關者。這是白費力氣去測試一個從來就不是風險所在的東西。
第二天——商店上架路徑，我還沒走完
這一項其實沒有真正完成，而這反而是更有用的心得。商店上架流程——Android 上 Google Play、擴充功能上 Chrome 線上應用程式商店和 Firefox Add-ons——需要透過你自己的開發者帳號，上架資訊與隱私聲明則由智慧代理準備。這部分是真的，但這本身也是一個獨立的多天流程，中間還有無人能控制的審核排程，所以我在完成上架資訊準備這一步後就停下了。如果你的目標是商店上架，請把這部分獨立估算時間；完整流程我寫在從提示詞到應用程式商店這篇文章裡。
當下是什麼決定了走哪條路
到了第二天，選擇幾乎是自然而然的：
| 我當時在做什麼 | 我選擇的路徑 |
|---|---|
| 測試這個點子是否有搞頭 | 子網域，當天就上線 |
| 需要一個正式的品牌網域 | 先用子網域，再用 SFTP 上傳到自己的伺服器 |
| 使用者會在商店裡找到的實用工具 | 子網域行銷頁面 + 應用程式的商店上架 |
| 客戶專案，架在他們的基礎設施上 | SFTP 上傳到他們的伺服器，並做版本管理 |
週末
到了週五，我在自己的網域上有了行銷網站、產品本身在子網域上線，還有一個準備到一半的商店上架資訊——這三條路徑同時並行，服務同一個專案，而且從頭到尾都是在同一個對話中建構與迭代出來的。這似乎才是任何認真專案的正常終局，而不是特例。真希望我從第一天就預期到這點，而不是把這三條路徑當成各自獨立的決定。
