程式碼之外的那座山

如果你以為一人做訂閱服務，難的是技術——這系列前面二十八天可能加深了這個誤會。到了要正式收錢的階段，你會發現真正的關卡陸續浮現在完全陌生的領域：公司登記、稅務、金流特約申請、各種需要外部單位審核的文件。

這些事的共同特徵，跟工程世界的規則完全相反。

兩個世界的規則差異

工程世界：問題有明確的錯誤訊息、除錯有方法論、進度由自己的投入決定、大多數問題當天有答案。

行政世界：流程的狀態不透明（送出去的申請此刻在誰的桌上？不知道）、時程不由你控制（審核要多久？「通常」幾週,但沒有 SLA）、而且投入更多努力不會加速——你不能對一個審核流程「加班」。

具體的體感：一個功能從構想到上線可能是一個晚上;一份需要外部審核的申請,從送件到回音可能是好幾週,中間你能做的事情是零。對習慣了「努力→進度」正反饋的工程師，這種「無法施力的等待」在心理上的消耗，遠比寫不出程式碼難受。

學到的三件事

一、行政流程要及早並行啟動，它往往才是關鍵路徑。 Day 15 講過金流地基「先蓋好等開燈」的策略，它的另一半正是這裡：工程線和行政線是兩條並行的路徑，總時程取決於慢的那條——而慢的那條幾乎永遠是行政。正確的排程思維是把「送出申請」當成專案最早的里程碑之一，而不是「等東西做完再來辦手續」。

二、每一步都問清楚「下一步卡在誰」。 行政流程的除錯技巧其實跟分散式系統很像：找出目前的 blocking point。是文件不齊？是在排隊等審？是對方在等你補件而你不知道？——最冤枉的延遲是「雙方都在等對方」的死鎖，而它發生的頻率高得驚人。定期主動查詢狀態，不是催促，是解死鎖。

三、把等待期變成其他線的衝刺期。 無法施力的等待之所以難受，是因為注意力閒置在焦慮上。解法是結構性的：行政線進入等待狀態時，立刻把注意力調度到工程線或內容線上——這個系列本身，有一部分就是在某段「等回音」的時間裡動筆的。

一人公司的「隱藏成本」總帳

回頭盤點，一人做商業服務的成本裡，帳單上看得到的（Day 28 那幾千元）其實是最小的一塊。看不到的大頭是：

• 時間成本：行政流程消耗的時間，以及它強制的等待
• 心理成本：不確定性、無法施力感、以及「所有決定都只有自己拍板」的孤獨
• 機會成本：這些時間精力如果投在別處的價值

我不覺得這些成本是勸退的理由——但它們應該出現在任何人下場前的計算裡。低估技術難度的人會做出爛產品，低估行政成本的人會做出好產品然後卡在上線前的最後一里路——後者更可惜。