設計哲學
一間 startup 的目標很簡單：快速打造出色的產品、撐到勝利，並建立一套不會把自己吃垮的高效營運體系。
不是打造最偉大的技術平台。不是讓其他工程師刮目相看。不是去實作大型科技公司在你幾年內都不會達到的規模下才會用到的架構。就只是打造一門好生意——並在時間和資金耗盡之前做到。
Orbital Express 之所以存在，是因為軟體開發中的每一個決策，本質上都是偽裝成技術決策的商業決策。你選擇的 framework 決定了你招募的速度、入職需要多久、工程師要花多少時間爭論而非開發、程式碼庫能不能撐過團隊換人，以及你是否會在凌晨兩點爬起來救火。這些不是技術成果，而是商業成果。
這個 framework 裡的每一個觀點，都是為了幫助你建立一門好生意——而不是一個偉大的技術平台。
瓶頸幾乎從來都不是技術本身，而是人——新成員入門要多久、大家花多少時間爭論架構決策、新人多快能做出真正有價值的貢獻，以及有多少團隊能量消耗在維運而非產品上。
核心原則
這個 framework 裡每一個有主見的選擇，都直接體現了以下一條或多條原則：
1. 低學習曲線勝過強大功能
一個工程師第一天就能上手的 framework，遠比一個三年後才能解鎖某些理論能力的 framework 更有價值。我們優化的是「第一次 commit」到「第一個功能上線」之間的時間——對每位工程師，每一次都是如此。
2. 有主見才能消除爭論
當 framework 做出選擇，你的團隊就不必再做。每一個開放性問題——用什麼狀態管理、什麼 router、什麼資料夾結構、什麼 HTTP method、什麼命名規範——都是引發爭論的邀請函。Orbital Express 把這些問題全部關上。你把省下來的時間拿去開發功能。
3. 一致性勝過聰明
每個檔案看起來都和其他檔案一樣的程式碼，才是任何工程師第一天就能上手的程式碼。沒有人能理解的「天才個人解法」是一種負債。我們的目標是讓程式碼活得比任何一個人都久——包括你自己。
4. 將培訓成本降至趨近於零
每一個非標準的技術選型都是培訓成本。每多一層，就是新工程師在能做出貢獻之前必須理解的新事物。每一個需要深厚專業知識才能正確使用的工具，都會縮小你的招聘範圍、拉長入職時間。我們在任何可能的地方都把這些成本剔除掉。
5. 團隊速度，而非個人速度
衡量一支好的工程團隊，不是看最強的工程師能多快交付，而是看整個團隊能多快交付——包括上個月才加入的那位工程師。讓一個人快 10%、卻需要三週時間教會其他所有人的決策，是壞決策。
這些原則如何落地
這五條原則驅動了 framework 中的每一個選擇：
- JavaScript，不是 TypeScript——因為一個編譯層、一套型別系統、以及數個月的學習曲線，並不能提升團隊的交付速度。
- Vue.js，不是 React——因為 React 的無主見特性意味著每位新成員都帶著自己的主見來，你花的時間是在裁判，而不是在開發。
- 單一 repo，不是微服務——因為五個 repo 意味著五套規範、五段入職體驗，以及凌晨兩點的跨服務除錯。
- 託管部署，不是 AWS——因為一支負責管理自建基礎設施的 DevOps 團隊，並沒有在開發功能。
而這一切背後：這個 framework 為何存在的故事——十年昂貴的錯誤究竟教會了我們什麼。
結論
你的 startup 正在與時間賽跑。你有一條資金跑道。你有一個競爭對手正在此刻交付功能。你有一批工程師，他們的時間每天都在消耗真實的金錢。能幫你快速打造出色產品、精簡營運、撐到勝利的 framework，才是正確的 framework。這，就是 Orbital Express 存在的意義。