世界を動かす技術を、日本語で。

月額20ドルのテクノロジースタックで複数の月額1万ドルの収益を上げる企業を運営しています

概要

  • 自作ツールでMRRを得ている が、VCから資金調達で何度も却下された経験
  • 徹底したコスト削減と効率化 による「ラン・リーン」な起業ノウハウの公開
  • AWS等の大規模インフラ不要、VPSやGo言語、ローカルAI、SQLite活用が中心
  • 独自プロダクトやOSSも紹介、GitHubでコード公開中
  • 複雑な構成や高額投資不要、少額でスケーラブルな事業構築法の提案

なぜVCは「何に資金が必要なのか」と問うのか

  • 既にMRRとユーザーが存在、プロダクト自体に問題なし
  • コストを極限まで抑えた運営、VCからは成長投資の必要性が見えにくい
  • 効率化・自動化への執着、ブートストラップ型起業家としての成功体験
  • 「無駄なコスト=ランウェイ短縮」 との認識、資金調達不要論
  • プレッシャーや複雑なガバナンス不要、自由度の高い経営スタイル

超ローコストなサーバー運用法

  • VPS(Linode/DigitalOcean)を月$5〜10で利用、AWSは不要
  • 1GB RAMでも十分対応可能、必要ならスワップファイルで拡張
  • 単一サーバー管理でトラブル対応も簡単、ログや再起動も一元管理
  • インフラ維持よりサービス提供を重視、不要な複雑化を避ける

高効率な開発言語とデプロイ戦略

  • Go言語を主力バックエンドに採用
    • 低メモリ・高性能 で小規模サーバーに最適
    • LLMによるコード解釈も容易
    • 依存地獄なしの静的バイナリ、scp一発で本番投入可能
  • PythonやRubyは非効率、Goのデプロイ簡便性を重視

ローカルAI活用によるコスト最適化

  • 自宅GPU(例:RTX 3090)でAI処理、API課金から解放
  • Ollamaで試行錯誤→VLLMで本番運用、バッチ処理高速化
    • VLLMはPagedAttentionで並列リクエスト高速処理
  • Transformer Labで高度なモデル学習も可能
  • 独自ツールlaconicやllmhubでLLM管理を効率化
    • 会話文脈の最適化やプロバイダー抽象化を実現

外部LLM利用時の最適ルーティング

  • OpenRouterを活用しAPI統合とフェイルオーバー自動化
    • Anthropic/GPT-4o/Claudeなどを一括管理
    • 障害時は自動で代替APIへ切替、ユーザーにエラーを見せない

AI開発環境のコスト最適化

  • GitHub Copilot+VS Codeで十分な生産性
    • Cursor等の高額AI IDEは不要
    • Microsoftの従量課金モデルを活用し、月$60未満で運用
    • 詳細プロンプトと自動修正指示でコスパ最大化

SQLiteによるシンプル&高速なデータ管理

  • 新規プロジェクトは必ずsqlite3から開始
    • Cインターフェース経由で超高速アクセス
    • WALモードで高い同時実行性を確保
  • 独自ライブラリsmhanov/authで認証も簡単実装
    • Google/Facebook/X/SAML対応、依存最小のシンプル設計

結論:本当に必要なものだけで起業する

  • 複雑な構成や高額インフラ・VC資金は不要
  • VPS+Go+ローカルGPU+SQLiteでスケーラブルな事業構築
  • ランウェイを最大化し、ユーザー課題解決に集中可能
  • OSSやツールはGitHubで公開中、コメント歓迎

Hackerたちの意見

もし私のように「MRR」が何を意味するのか気になっている人がいたら、どうやら「月次継続収益」のことみたいだよ。

ARR(年間定期収益)ってのもあって、みんながARRを使うときは、だいたい今のMRRを基に数字をでっち上げてるだけだから、要するに嘘をついてるんだよね。ビジネスを始めて2ヶ月でARRを発表する人も見たことあるよ!

何も学べなかった。これのほとんどは基本的なアドバイスがAIで書かれた段落にまとめられてる感じだね… タイトルからして、成功するアイデアをブレインストーミングして立ち上げることについてだと思ってたんだけど。

通常、「月〇ドル」の時は基本的なアドバイスを聞くことになるよ。多くの人がこれを知らないってことに驚くかもね!

いいと思うよ。OPが言ってるリソースのインフレは確かに企業で見たことがある。AWSやスパークの巨大なクラウドベースのソリューションを求める一方で、cronジョブでpandasを使ったPythonスクリプトの方が速かったりするからね。

気が向いたら、ブログを始めてみて!君が基本的な知識だと思ってることでも、興味を持ってる人たちがいるからね。彼らはそれが存在することすら知らないかもしれないよ。

それだけじゃなくて、彼のビジネスモデルは「AIバブルで利益を得て、大手テック企業に間接的に補助金をもらう」って感じだよね。これがうまくいくのは明らかで、同じことをしてるマルチミリオンダラーのスタートアップがたくさんあるし。それでも、ちょっと…ありきたりに感じる?

時々、Claude 3.5 SonnetやGPT-4oの最先端の推論が必要な時があるよね。まさにその通り。

いいリストだね! SQLiteのWALが一番お金を節約できるポイントだと思う。ひとつ注意点として、PythonやNodeもGoと同じくらい使えるよ。Hetznerでは、4GBのRAM、10TBのネットワーク(その後は1TBあたり1ドルの出口料金)、2CPUのマシンが5ドルで提供されてる。VPSに関する2つの注意点:専用サーバーを使ってるなら、DBをストレージボックスに頻繁にバックアップするのを忘れないでね(1TBで月3ドル、rsyncを使って)。どちらにしてもいい習慣だけど、クラウドインスタンスの方がハードウェアの故障に対して信頼性が高いみたい。あと、彼らのオブジェクトストレージは避けた方がいいよ。セキュリティは自分で責任を持つからね。基本的なSSHの強化をスキップして、1時間以内にボットに感染する良い開発者も見たことがある。サーバーを立ち上げるときの私の定番は、二段階のTerraformセットアップだよ。まず、自分のIPだけを許可してSSHを設定して、Tailscaleをセットアップしてから、パブリックSSHのIPエントリーポイントを完全にシャットダウンする。気をつけて楽しんでね!

いいリストだね! SQLiteのWALが一番お金を節約できるポイントだと思う。面白いことに、最近古いDjangoのウェブサイトを少しモダンなアーキテクチャ(ベアメタルのuWSGIの代わりにdocker composeとuvicorn)に移行したんだけど、その時にPostgreSQLが全く必要ないことに気づいたんだ。古いサーバーにはすでにインストールされてたから、怠けた選択だったんだよね。データを全部ダンプしてSQLiteのWALに入れたら、今はずっとメンテナンスもバックアップも楽になったよ。

セキュリティについて、恥ずかしい話があるんだけど、昔、デフォルトパスワードのPostgreSQL DBを新しいVPSに置いて、パスワードログインを無効にするのを忘れたことがあって、ドメインもないサーバーで。そしたら1日でハッキングされて、ボットサーバーとして使われてた。あれは10年前の話。最近もサーバーを立てたら、1時間以内にSSHログインの試みがあったし、ドメインもなかった。幸い、教訓を得て、サーバーが立ち上がったらすぐにパスワードログインをオフにしたよ。似たような試みでデスクトップが動かなくなったこともあったし。今や、世界にオープンなマシンを持つのはすごく怖いね。Tailscaleみたいなサービスがあって本当に良かった。

それに、彼らのオブジェクトストレージは避けた方がいいよ。なんでそう言うのか気になるな。自分はlitestreamを使ってHetznerのオブジェクトストレージにバックアップしてるけど、今のところうまくいってるよ。たぶん、ストレージボックスより高いのかな?よくわからないけど、cronジョブとか設定しなくていいのは楽だね。

WALって本当に複数の同時書き込みをサポートしてるの?DBについてあんまり詳しくないんだけど、ググってみたら、書き込み中でも同時に読み取りはできるって言ってる人が多いけど、同時書き込みは無理って言ってる人もいるんだよね。みんながそう言ってるわけじゃないし… だから、WALについて正しい考え方を教えてくれる人いる?

開発者がSSH経由で1時間以内に感染するっていう話、もっと情報が欲しいな。もし彼らがめちゃくちゃ弱いrootパスワードを使ってたり、VNCを放置してたなら信じられないけど。

まず最初に、SSHを正しく設定することが大事で、次にファイアウォールを有効にして、SSHのポート以外のすべての受信接続をブロックすることだね(SSHは別のポートで/Web/SSL)。これで一気に多くの問題が解消されるよ!

企業のマインドセットは、プロセス外のデータベースサーバーが必要だと示唆している。しかし、実際には、ローカルのSQLiteファイルがCインターフェースやメモリを介して通信する方が、リモートのPostgresサーバーにTCPネットワークを経由するよりも桁違いに速い。SQLiteをけなしたくはないけど、素晴らしいし、多くのウェブアプリには十分すぎるほどだ。でも、ローカルホストでUnixドメインソケットを介してPostgres(あるいは他のDBでも)に接続すれば、ほとんどのオーバーヘッドを避けられる。SQLiteより使うのが難しいわけじゃないし、Postgresの機能をすべて使えるし、別のボックスからライブDBでレポートを出したりするのも簡単だし、リードレプリカやHAを設定したり、アプリとは別のボックスでDBを運用するのもずっと楽だよ。アプリと同じボックスでPostgresを運用するのは、Kubernetesクラスターを設定するのとは同じレベルの楽観的な過剰プロビジョニングではないと思う。

SQLiteより使うのが難しいわけじゃないし、Postgresの機能が全部使えるし、別のサーバーからライブDBでレポートを出したりするのも簡単だよ。リードレプリカやHAを設定するのも、アプリとは別のサーバーでDBを動かすのもずっと楽だし。ちょっと手間をかけてYAGNI機能を得るっていうのは、まさにTFAが反対してることじゃないの?

事実については間違ってないけど、SQLiteから別のPostgresサーバーにデータを移行するのはそんなに難しくないよ。結局その機能が必要になることもあるからね。でも、大抵は必要ないんだよね。

オーバーヘッドは無視できないみたいだね:100,000回のSELECT 1クエリを実行した結果:PostgreSQL(localhost):2.77秒、SQLite(インメモリ):0.07秒。

著者自身の「auth」プロジェクトは、SQLiteとPostgresで動いてるよ。

極端なスループットシナリオでSQLiteを拡張して使ったことがある。毎秒何百万ものドキュメントを処理して、曖昧さを解消するためにね。リモートサーバーでこれができなかったとは言わないけど、かなりの技術的挑戦だっただろうね。代わりに、データベースをS3にパックして、各インスタンスが新しいコピーを取得して、タスクに取り組んだんだ。SQLiteは、パフォーマンスが必要なときの信頼できる選択肢だよ、機能じゃなくてね。

俺はそれを何十年もやってるけど…人々はUnixアーキテクチャについて知らないみたい。sqliteの好きなところは、ただの一つのファイルで済むところだね。

同じマシンでドメインソケットを使っても、sqliteはpostgresを圧倒してるよ[1]。複数のsqliteデータベースを使う前の話ね。単一のマシンでモノリシックアプリを実行する場合、postgresがsqliteに対して提供する機能は何なの?アプリケーション機能[2]を使えば、アプリを作るのと同じ言語で必要なように拡張できるし、litestreamのおかげでバックアップとレプリケーションもずっと良いよ[3]。 - [1] https://andersmurphy.com/2025/12/02/100000-tps-over-a-billio... - [2] https://sqlite.org/appfunc.html - [3] https://litestream.io/ sqliteの主な問題は、デフォルトがあまり良くないこと。アプリケーションが書き込みキューを管理する形で、読み取りと書き込みの接続を分けて使うべきだね。

確か、localhost経由のTCP/IPはUnixソケットよりも速いベンチマークが出てたんだよね。最適化がしっかりされてたからかも。今は直ってるかもしれないけど。Unixソケットは接続してるユーザーIDに基づいた認証の利点があるよね。サーバーベースのアプリでsqliteを使った経験から言うと、アプリが成長するにつれて、ほぼ必ずsqliteより大きなものが必要になって、結局移行することになるんだよね。デプロイの複雑さを最小限に抑えることがそれほど重要じゃないサーバーベースのアプリなら、読み書きが混在する場合、最初からPostgresやMariaDBを使うのは悪くない選択だと思う。確かに、サーバー上でsqliteが良い場合もあるけど、それはごく限られたケースだよね。

それはただ別の企業向けの懸念を混ぜてるだけだよ。データベース接続のレイテンシは、システムの中で全然気にするべき部分じゃない。

オーダー・オブ・マグニチュードニュース

1GBのRAMに制限する理由なんて全くないよ。5ドルの代わりに20ドル払えば、少なくとも8GBのRAMが手に入る。キャッシュや同時書き込みをサポートするデータベースに使えるしね。15ドルの差は、小さなビジネスを運営する上では経済的な違いにはならないよ。5ドルのVPSに全てを収めようと考えるのは、ビジネスには役立たないからね。

$15って、ゼロじゃないよね?1GB以上必要ないなら、なんで1GB以上のためにお金を払うの?20年前に128MBくらいのサーバーでLAMPスタックを動かしてたけど、メモリの問題はあまりなかったよ。今のウェブサイトのバックエンドは、余計なものを入れなければ、当時とあまり変わらないくらいシンプルだし。

でも、彼らはそれをどうフィットさせるか考えてるわけじゃないみたい。単に良いテンプレートを使ってるだけ。

NVMEの読み取りレイテンシは約100μsで、低テラバイトのSQLite3データベースは、ポイントルックアップごとに3〜5のランダムIOが必要だから、すでに意味のあるデータ量での最悪のケースは、コールドルックアップで約0.5msってところ。アプリが複雑でリクエストごとに10回これを行うと、5msになる。そうすると、キャッシュが必要になる前に200リクエスト/秒を処理できるってわけ。これは1日あたり1700万ヒット、約3.9 MiB/secの持続的なディスクIOになる。ほぼどんな安いNVMEドライブでも並列処理ができるから(数字を少なくとも4倍にできる)、それを考慮しないといけないけどね。でも、リクエストを一つも処理する前にインフラ支出が4倍になるってのが、この記事のポイントなんだよ。

HetznerやOVHなどは、同じくらいの価格で4〜8GB、2〜4コアを提供してるよ。

現代のシステムでスワッピングを使ってCPU支援のページ圧縮や高速なNVMeドライブを利用する際のRAM使用について、再考する必要があると思う。8GB RAMのMacbook Neoは、発売前にRAMの少なさからその能力を過小評価されてたけど、リリース後はレビューアーたちが予想外の大きな能力を指摘してるよね。

それなら、Hetznerみたいなヨーロッパのプロバイダーを選んで、8GBのRAMを10ドルくらいで手に入れるのがいいよ。:) 彼らの5ドルプランでも4GBがもらえるし。

1GBのRAMに制限する理由はゼロだよ。 いい理由があるよ。それは、過剰な設計や過剰なリソースを避けて、顧客にビジネス価値を提供することに集中することを自分に教えるため。多くのエンジニアが楽しい技術的な詳細の裏に隠れていることを見落としがちだと思う。

SQLiteは悪くないけど、$20のサーバーでPostgreSQLを問題なく動かしたことがあるから、同時にユーザーやタスクを扱うならPostgreSQLがオススメだよ。SQLiteのWALも動くけど、同時にたくさんのタスクが走ってるときに問題が起きることもあったし。あくまで私の感覚だけど、大きなテキストデータを扱うならPostgreSQLの方がストレージが最適化されてる気がする。SQLiteだとストレージがいっぱいになったけど、同じアプリをPostgreSQLで動かしたときはそんな問題なかった。

これが基本的なアドバイスに聞こえるかもしれないけど、サーバーレスやKubernetes、サーバーの群れ、プラネットスケールのデータベース、マルチゾーンの高可用性セットアップ、その他の「ベストプラクティス」から始めなきゃいけないと思ってる人がたくさんいるんだよね。「安いVPSで動かせばいいじゃん」って言うと、すぐに「スケーリングは?」「高可用性は?」「バックアップは?」「それを維持しなきゃいけないじゃん」って反論が返ってくる。これって、いろんなクラウドプラットフォームのセールストークをそのまま繰り返してるだけなんだよね。学習された無力感ってやつ。

どうやら「カーゴカルトソフトウェアエンジニアリング」って言葉はもう一般的じゃないみたい。これらのことを完璧に説明してるね。

なんて言えばいいかわからない。みんなこのエンジニアたちが存在すると言うけど、俺は一人も見たことがない。インディハッカーコミュニティをたくさんフォローしてるのに。

LinodeかDigitalOceanを使ってるよ。月に5ドルから10ドル以上は払わない。1GBのRAMは現代のウェブ開発者には恐ろしいかもしれないけど、ちゃんとやり方を知ってれば十分なんだ。複数のプロジェクト用に1台の専用サーバーを使えば、コストを抑えつつ制約を緩めることもできるよ。例えば、Hetznerのサーバーオークションを見てみて:https://www.hetzner.com/sb/ これに月約40ユーロ払ってるよ:ディスク:736G / 7.3T (11%) CPU:Intel Core i7-7700 @ 8x 4.2GHz [42.0°C] RAM:18004MiB / 64088MiB Proxmoxをインストールして、OSのIO負荷が許す限りVMを作れるよ:https://www.proxmox.com/en/ (ストレージを重視したからRAID 0のHDDを使ったけど、他の人はSSDのサーバーを選ぶかもね)15台のVMをそれぞれ4GBのRAMで運用しても、1台あたり月2.66ユーロくらいになるよ。通常のVPSと比べて、どんな規模(プロジェクトの数)でもコスト効率が圧倒的に良いし、ゴミを載せなければProxmox自体もかなり安定してるよ。もちろん、中古の機材を使うならバックアップは必要だけど、それはどんな場合でも必要だしね。それ以外にも、HetznerやContabo(これに関しては意見が分かれるけど)は、通常のVPSホスティングでももっと安いよ。Scalewayも本当に安いStardustインスタンスがあったと思うけど、すぐに売り切れちゃうんだよね。

IPv4についてはどうしてる?ルーティング用のVMを使って管理してるの?ハイパーバイザーを使って大きなVMをレンタルする人たちがいるのはすごく興味深いね。商業規模でこれを防ぐ条項がVPSのライセンスにあるのか気になるな。

SQLITE + Litestreamでテナントごとのデータベースを運用してる人いる?経験や苦労した点を共有してほしいな。移行が一つの課題だって知ってるけど、他に何かある?リクエストから正しいデータベースを見つけるのも難しいよね。他には?

SQLiteが大好きで、ネットワークドライブでもキューイングされた書き込みを使って、読み込みが多いアプリケーションで運用してたこともあるよ。すごく堅牢なソフトウェアで、月に数ペニーで10万人以上のユーザーにサービスを提供できたこともあった。でも、Postgresみたいなしっかりした専用のデータベースサーバーが必要な時と場所もあるよね。