以商業為優先，而非工程師
一間 startup 的目標，是快速打造出色的產品、撐到勝利，並建立一門好生意。不是打造偉大的技術平台。
這個區別聽起來很顯而易見。但實際上，startup 裡幾乎每一個工程決策都走錯了方向——優化的是技術正確性，而不是商業存活。你選的 framework、用的語言、採用的架構、建的基礎設施——這些全都被當作技術決策來對待。它們不是。它們是帶有技術後果的商業決策。
你聽過的每一個熱門 framework，都是由工程師為工程師打造的。它們解決的是工程問題：如何組織程式碼、如何處理型別、如何擴展到百萬請求、如何部署到 Kubernetes。這些都是真實的問題——但它們不是你的問題。
你的問題截然不同。你需要在競爭對手之前發布某個功能。你需要新進人員在一週內就能做出實質貢獻，而不是一個月後。你需要避免那個當時看起來正確、但每月燒掉一萬美元的基礎設施決策。你需要兩年後的工程團隊，在換了一批人之後，仍然保持快速前進的能力。
Orbital Express 是第一個為解決這些問題而打造的後端 framework。
其他 framework 優化的目標
Rails、Django、Laravel、NestJS、FastAPI——這些都是優秀的 framework，由聰明人打造，技術能力深厚。
但它們也是由熱愛工程的人，為熱愛工程的人所建造的。它們的決策反映的是工程師的價值觀：
- 彈性 — 支援所有可能的使用情境，即使你永遠不會用到
- 技術正確性 — 強制執行架構上純粹的模式
- 開發者體驗 — 讓在這個 framework 裡寫程式感覺良好
- 功能完整性 — 增加更多功能、更多選項、更多能力
- 社群認可 — 遵循資深工程師期待的模式
這些不是壞的價值觀。但請注意清單裡缺少什麼：成本、速度、入職時間、招聘、團隊速度、營運負擔、工程總支出。這些才是創辦人或 CTO 真正夜不成眠的事。
當一個 framework 做出你不認同的決定時，你會繞過它。而每一個繞過的方式，都是下一位工程師需要學習的自訂模式。這個成本在技術審查中看不見，但在你的季度工程預算中卻清晰可見。
Orbital Express 優化的目標
我們在每個 framework 決策前問的問題不是「這在技術上是否正確？」而是：商業需要什麼？
| 工程師的考量 | 商業現實 |
|---|---|
| 架構優雅性 | 每週發布的功能數量 |
| TypeScript 型別安全 | 新進人員需要 3 個月才能上手 |
| 微服務自主性 | 每年 40,000 美元的 DevOps 薪資 |
| Framework 彈性 | 6 個月重寫上一個團隊建立的東西 |
| 開發者自我表達 | 巴士因子：那位工程師離職後會怎樣 |
| 可擴展性抽象 | 凌晨兩點跨 17 個服務除錯 |
當這兩欄發生衝突時，大多數 framework 選擇左欄。Orbital Express 選擇右欄。
Framework 決策的真實成本
讓我們具體說明「錯誤的 framework 決策」實際上要付出多少代價。
入職成本。 一位資深工程師的年薪平均為 180,000 美元。以這個薪資計算，每個月的入職時間就要花費 15,000 美元——僅是薪資，還未計算必須指導他們的資深工程師的時間。一個能將入職時間從三個月縮短到三週的 framework，每次招聘就為你節省 30,000 美元。這是一個偽裝成技術決策的商業決策。
工程師爭論。 每一個開放的架構問題——什麼資料夾結構、什麼命名慣例、什麼 HTTP 模式、什麼錯誤格式——都會變成一次團隊會議、一串 Slack 訊息或一場 PR 留言戰。資深工程師的時薪是 90 至 150 美元。一個下午的架構辯論，花費比這個決策本身的價值還高。Orbital Express 替你做出這些決定，那些時間都回去用於發布功能了。
巴士因子。 當你的首席工程師離職時會發生什麼？如果你的程式碼庫是圍繞那位工程師的個人風格和架構偏好建立的，答案是：一場昂貴的過渡期。如果你的程式碼庫建立在 Orbital Express 上，答案是：你招募另一位工程師，他在幾分鐘內就能讀懂任何檔案。傳統觀點把巴士因子視為技術風險，它其實是商業持續性風險。
重寫週期。 每個繼承了缺乏強烈慣例的程式碼庫的團隊，最終都會重寫它。重寫要花費數個月的工程時間、引入回歸問題，且在進行期間什麼新東西都不會發布。平均重寫需要六個月。以三人團隊每人年薪 200,000 美元計算，就是花費 300,000 美元的薪資，最終回到了起點。Orbital Express 被設計為永遠不需要重寫的 framework——因為慣例足夠強烈，每位工程師都是在擴展現有模式，而不是取代它們。
工程師時間是你購買的最昂貴的東西
大多數創辦人在抽象層面理解這一點。Orbital Express 的建立是為了在具體層面認真對待它。
每當工程師花時間在：
- 與不熟悉的 framework 概念搏鬥
- 與同事辯論架構選擇
- 閱讀沒有任何可辨別模式的程式碼
- 維護本可以是託管服務的自訂基礎設施
- 跨不必要存在的服務邊界除錯
……那就是沒有花在建立產品的時間。那可能是你的競爭對手正在用來發布你還沒做的功能的時間。
技術社群讚美複雜性。大型科技公司發布關於其 40 個服務架構、自訂部署管道、monorepo 工具的工程部落格文章。這些是令人印象深刻的解決方案，針對的是他們規模所帶來的問題。你的新創公司還沒有達到他們的規模，複製他們的架構會帶來他們的營運成本，卻沒有他們的營運需求。
每週發布功能的無聊 monolith，正在擊敗每月發布功能的微服務架構。能在第一天閱讀任何檔案的工程師，比需要三年才能解鎖理論能力的 framework 更有價值。
AI 乘數效應——一個商業論據
AI 程式助手是真實存在的，它們正在改變小型工程團隊所能完成的事情。但「AI 寫程式碼」和「AI 寫出符合你架構的正確程式碼」之間存在差距。
這個差距就是一致性。AI 工具是模式匹配器。它們非常擅長擴展一致的模式，在任意程式碼庫中發明新模式則非常糟糕。
在基於 Orbital Express 建立的程式碼庫中：
- 每個功能資料夾看起來都一樣
- 每個 action 遵循相同的結構
- 每個錯誤遵循相同的格式
- 每個測試遵循相同的模式
當你向 Claude 描述一個功能時，它讀取操作手冊、執行產生器，並擴展它在程式碼庫各處看到的模式。輸出在結構上是正確的——不是因為 AI 聰明，而是因為 framework 讓「正確」成為唯一的路徑。
商業影響：使用 Orbital Express 搭配 AI 的團隊，可以以兩倍規模團隊的速度發布功能。這不是技術優勢，這是招聘預算優勢。這是資金跑道優勢。這是競爭優勢。
由親身付出商業代價的人打造
這個 framework 不是在真空中設計的。它是在目睹十年糟糕的技術決策變成昂貴的商業問題之後建立的——在一個一千萬美元的教訓之後，那個教訓告訴我們，當你為工程滿意度而非商業成果優化時會發生什麼。
選擇使用純 JavaScript 而非 TypeScript，不是技術偏好。這是影響真實預算項目的招聘決策和入職決策。選擇建立 monolith 而非微服務，不是懶惰。這是對在新創規模下不提供任何價值的營運複雜性的刻意拒絕。選擇使用託管主機而非 AWS，不是天真。這是消除整個工程費用類別的決定。
這個 framework 中的每個觀點都有一個價格標籤。我們選擇了總擁有成本最低的觀點——不是為了今天寫程式碼的個別工程師，而是為了在未來五年為工程師付費的商業。
結論
你的 startup 正在與時間賽跑。你有一條資金跑道。你有一個競爭對手正在此刻交付功能。你有一批工程師，他們的時間每天都在消耗真實的金錢。
正確的 framework 不是最令人印象深刻的那個。不是跑分最好、生態系最大、或讓資深工程師在 code review 時點頭稱許的那個。正確的 framework 是能幫你快速打造出色產品、精簡營運，並撐到勝利的那個。
如果你是一位熱愛為其本身而建立複雜系統的工程師，Orbital Express 會讓你感到受限。這是刻意的。
如果你正在建立一門生意——這個 framework 是為你打造的。
停止為工程辯論付費。開始發布。