我知道如何在網路上製作和銷售軟體，並且我很樂意與你分享我的技巧。

昨晚，我又一次在提案之夜被拒絕了。這只是初選面試，問題不在我的產品。我已經有月營收（MRR），也有用戶每天依賴我的產品。

得到的評價是：「你到底需要什麼資金？」

當我試圖擴展我的想法時，我總是聽到這樣的話。精實經營是我的天性。我曾開發過你可能用過的工具，例如 websequencediagrams.com，以及你可能沒用過的利基產品，例如 eh-trade.ca。這種對效率的執著造就了成功的自力更生，老實說，很多創投公司討厭這一點。

將成本維持在接近零的水平，能讓你獲得與獲得百萬美元資金但燒錢速度極快的公司相同的營運時間。這樣壓力更小，架構更簡單，並且有足夠的時間找到產品市場契合點，而無需承受董事會的壓力。

如果你厭倦了現代的「企業級」樣板，這就是我如何以幾乎零成本建立公司的確切方法。

在 2026 年推出網路應用程式的幼稚方法是啟動 AWS，配置 EKS 集群，設置 RDS 實例，配置 NAT Gateway，然後在第一個用戶看到你的登陸頁面之前，意外地花費每月 300 美元。

聰明的方法是租用單一虛擬私人伺服器 (VPS)。

我做的第一件事就是找一個便宜、可靠的伺服器。忘掉 AWS。你不需要它，而且他們的控制面板就像一個旨在誘使你升級帳單的迷宮。我使用 Linode 或 DigitalOcean。每月支付不超過 5 到 10 美元。

1GB 的 RAM 對於現代網路開發人員來說聽起來很可怕，但如果你知道自己在做什麼，那就足夠了。如果你需要一點緩衝空間，可以使用交換文件。

目標是處理請求，而不是維護基礎設施。當你只有一台伺服器時，你確切地知道日誌在哪裡，確切地知道它為什麼崩潰，以及確切地知道如何重新啟動它。

現在你有了限制。你只有一 GB 的記憶體。你可以使用 Python 或 Ruby 作為你的主要後端語言——但為什麼要這麼做？你將花費一半的 RAM 來啟動解釋器和管理 gunicorn 工作程序。

Go 在網路任務方面具有無與倫比的效能，它是嚴格類型的，並且——對 2026 年來說至關重要的是——它對大型語言模型 (LLM) 來說非常容易理解。但 Go 的真正魔力在於部署過程。沒有 pip install 的依賴地獄。沒有虛擬環境。你在筆記本電腦上將整個應用程式編譯成一個單一的、靜態連結的二進位文件，將它 scp 到你的 5 美元伺服器上，然後運行它。

這是一個完整的、生產就緒的 Go 網路伺服器。不需要臃腫的框架：

如果你家裡有一張顯示卡，你已經擁有無限的 AI 點數。

當我開發 eh-trade.ca 時，我遇到了一個具體問題：我需要對數千家公司進行深入的、定性的股票市場研究，並總結大量的季度報告。幼稚的解決方案是將所有這些都發送給 OpenAI API。我可能需要支付數百美元的 API 點數，結果卻發現我的提示循環中存在一個邏輯錯誤，需要我重新運行整個批次。

相反，我在一張塵封的、900 美元的顯示卡（一張帶有 24GB VRAM 的 RTX 3090）上運行 VLLM，這張卡是我從 Facebook Marketplace 上買的。這是一筆前期投資，當然，但我再也不需要為批次處理向 AI 提供商支付費用了。

對於本地 AI，你有一個明確的升級路徑：

為了管理這一切，我開發了 laconic，這是一個專為在受限的 8K 上下文窗口中運行而優化的代理研究員。它像作業系統的虛擬記憶體管理器一樣管理 LLM 上下文——它將對話中不相關的部分「分頁出去」，只將最關鍵的事實保留在活動的 LLM 上下文窗口中。

我還使用 llmhub，它將任何 LLM 抽象成一個簡單的提供者/端點/API 金鑰組合，無論模型是在我的桌下運行還是在雲端運行，都能優雅地處理文本和圖像 IO。

你無法在本地完成所有事情。有時你需要 Claude 或 ChatGPT 的絕對尖端推理能力來進行面向用戶的、低延遲的聊天互動。

與其在 Anthropic、Google 和 OpenAI 的帳單帳戶、API 金鑰和速率限制之間周旋，我乾脆使用 OpenRouter。你在程式碼中編寫一個與 OpenAI 相容的集成，即可立即訪問所有主要的尖端模型。

更重要的是，它允許無縫的備份路由。如果 Anthropic 的 API 在週二下午出現故障（這種情況確實會發生），我的應用程式會自動備份到一個等效的 OpenAI 模型。我的用戶永遠不會看到錯誤畫面，我也無需編寫複雜的重試邏輯。

同時，我整天使用 Claude Opus 4.6，我的帳單幾乎沒有超過 60 美元。我的秘密是什麼？我利用了微軟的定價模式。

這是一個你可能錯過的技巧：不知何故，微軟能夠按請求收費，而不是按代幣收費。而「請求」僅僅是我在聊天框中輸入的內容。即使代理花費接下來的 30 分鐘時間處理我的整個程式碼庫，映射依賴關係，並更改數百個文件，我仍然只支付大約 0.04 美元。

最佳策略很簡單：編寫嚴格詳細的提示，並設定嚴格的成功標準（這本來就是最佳實踐），告訴代理「持續執行直到所有錯誤都修復」，然後按 Enter 鍵，去泡杯咖啡，讓 Satya Nadella 為你的計算成本買單。

我總是使用 sqlite3 作為新創業務的主要資料庫。聽我說，這並沒有你想像的那麼瘋狂。

企業思維認為你需要一個獨立於進程的資料庫伺服器。但事實是，透過 C 介面或記憶體進行通信的本地 SQLite 文件，其速度比發起 TCP 網路連接到遠端 Postgres 伺服器要快幾個數量級。

「但是並發性呢？」你問。許多人認為 SQLite 在每次寫入時都會鎖定整個資料庫。他們錯了。你只需要開啟寫入預寫日誌 (WAL)。打開資料庫時執行一次此 pragma：

好了。讀者不再阻塞寫入者。寫入者也不再阻塞讀者。現在你可以輕鬆地處理來自單個 .db 文件（位於 NVMe 驅動器上）的數千個並發用戶。

由於實現使用者身份驗證通常是開始新的 SQLite 專案中最令人討厭的部分，所以我建立了一個函式庫：smhanov/auth。它直接與你正在使用的任何資料庫集成，並管理使用者註冊、會話和密碼重置。它甚至允許使用者使用 Google、Facebook、X 或他們自己的公司特定 SAML 提供者登入。沒有臃腫的依賴項，只有簡單、可審核的程式碼。

科技行業希望你相信，建立一個真正的企業需要複雜的協調、龐大的每月 AWS 帳單和數百萬美元的創投資金。

透過利用單一 VPS、靜態編譯的二進位文件、用於批次 AI 任務的本地 GPU 硬體以及 SQLite 的原始速度，你可以白手起家創辦一家高度可擴展的新創公司，其成本低於每月幾杯咖啡的價格。你為你的專案增加了無限的營運時間，讓你有時間真正解決用戶的問題，而不是為你的燒錢速度而煩惱。

如果你對精實經營感興趣，請在我的 GitHub 上查看我的身份驗證函式庫和代理實現。我會在評論區閒逛——讓我知道你是如何降低伺服器成本的，或者告訴我為什麼我完全錯了。