Fewtech

Nomad List — 1人で、年間3億円規模のプロダクトを、枯れた技術だけで支える理由

Pieter Levelsが2014年に1人で立ち上げたNomad List。Vanilla PHP・jQuery・SQLiteという枯れた技術構成のまま、年間3億円規模の売上を1人で支え続けている。その技術的な意思決定の裏側を追う。

2026.09.04読了目安 13Fewtech編集部 取材
この記事の要点
  • 1枚のスプレッドシートで需要を検証してからWebサイト化する、検証優先の開発プロセス
  • Vanilla PHP・jQuery・SQLiteという「枯れた技術」をあえて選び続ける経済合理性
  • 180以上の自動化と1台のVPSにより、1人で複数プロダクトを同時運用する仕組み

Nomad Listは、Pieter Levels(@levelsio)が2014年に1人で立ち上げた「デジタルノマド向け都市ランキング」サービスだ。都市ごとの生活費、ネット速度、治安、気候などをスコア化し、住むべき場所を探せるようにする——今では年間3億円規模の売上を、彼はたった1人、しかも枯れた技術だけで支え続けている。

Fewtechが最初に紹介したいのは、まさにこの1本だ。少人数開発の象徴のようなプロダクトでありながら、その技術的な判断はきわめて地味で、実務的で、再現性がある。

📷 画像プレースホルダー:都市ごとの生活費・ネット速度・治安などをスコア化して並べたランキング画面(要スクリーンショット差し替え)

前史:うまくいかなかった6つの挑戦

Nomad Listは、Pieter Levelsにとって最初のプロダクトではない。彼はそれ以前に6つのプロダクトを作り、いずれも大きな成功には至らなかった。失敗を重ねる中で身についたのが、「まず動くものを最速で出す」「重厚な設計より検証を優先する」という姿勢だった。Nomad Listの技術的な選択は、この前史を抜きにしては理解できない。

始まりは、1枚のスプレッドシート

Nomad Listはアプリとしてではなく、1枚のGoogleスプレッドシートとして生まれた。都市ごとの生活費やネット速度を手作業でまとめ、Twitterで公開したところ、想像以上の反響があった。

🐦 埋め込みツイート推奨箇所:ここに、当時のスプレッドシート公開時の実際の投稿(@levelsio、2014年)を埋め込む。

需要が確認できて初めて、Webサイトとしての開発に着手する——これがPieter Levelsに一貫する検証優先の姿勢であり、Nomad Listの技術スタックの選定にもそのまま引き継がれている。

Webサイト化とProduct Huntでの初速

スプレッドシートの反響を受けて、Pieter Levelsは数日でシンプルなWebサイトを組み上げ、Product Huntに投稿した。ここでの目的は美しいUIではなく、「都市を検索して比較できる」という中核機能を最短で届けることだった。

📷 画像プレースホルダー:初期バージョンのNomad Listサイト画面(要スクリーンショット差し替え)

技術的な意思決定①:あえて「枯れた技術」を選び続ける理由

Nomad Listのバックエンドは、今なおVanilla PHP・jQuery・SQLiteという構成が中心になっている。モダンなフレームワークが次々登場する中でも、Pieter Levelsはこの構成を大きく変えていない。

なぜSQLiteで十分なのか

  • サーバーを分離する必要がなく、バックアップもファイルコピーで完結する
  • 小〜中規模のトラフィックであれば、性能上のボトルネックになりにくい
  • 障害点が少なく、1人で運用する上で「壊れにくさ」が最優先される

コスト構造から見える経済合理性

フレームワークの学習・移行コストをかけず、枯れた技術をそのまま使い続けることで、開発時間のほぼすべてを機能や検証に振り向けられる。年間3億円規模の売上を1人で支えるには、技術選定そのものが経営判断になっている。

技術的な意思決定②:デプロイと運用の哲学

Nomad Listは、大規模なクラウドインフラではなく、比較的シンプルなVPS上で運用されている。オーケストレーションツールやマイクロサービス化を避け、1台のサーバーで完結する構成を保つことで、運用の複雑性そのものを削減している。障害が起きた際に「どこで何が起きているか」を1人で即座に把握できることが、可用性より優先されている。

働き方:ミーティングゼロ、フィードバックは公開の場で

Pieter Levelsには、社内会議も承認フローも存在しない。ユーザーからのフィードバックはTwitter(X)上で直接受け取り、そのまま製品判断に反映する。意思決定のスピードは、組織構造をなくすことによって生まれている。

複数プロダクトへの展開

Nomad Listで確立した「枯れた技術・高速な検証・1人運用」というモデルは、その後の複数プロダクトにも展開されている。

  • Remote OK — リモートワーク求人サイト
  • Photo AI — AI写真生成サービス
  • InteriorAI — AIインテリアデザインサービス

🐦 埋め込みツイート推奨箇所:複数プロダクトの合計MRRを公開した際の投稿を埋め込む。

📷 画像プレースホルダー:Pieter Levelsが公開している複数プロダクトの収益ダッシュボード(要スクリーンショット差し替え)

派手な成功の裏にある、70の挑戦

Pieter Levelsはこれまでに70以上のプロダクトを試みており、大きく成功したのはそのうちのごく一部だと公言している。Nomad Listの成功は、技術力や運の良さだけでなく、失敗を安く速く重ねられる技術選定と働き方の積み重ねの結果だと言える。

まとめ:技術的な意思決定が、生存戦略そのものになっている

Nomad Listのケースが示すのは、次のような判断の積み重ねだ。

  • 枯れた技術を選ぶことは、機能不足ではなく「壊れにくさ」への投資である
  • インフラのシンプルさは、1人運用における最大のリスク管理手段になる
  • 検証を先に、開発を後にする順序が、失敗のコストを最小化する

わずかな人数と、その技術的な判断。Fewtechが最初に紹介したいのは、まさにこの1本だ。

参考にした情報源(一次情報中心)

  • @levelsio — Pieter Levels 本人のX(Twitter)アカウント
  • levels.io — Pieter Levels 本人のブログ
この記事をシェアX (Twitter)Facebook