ScreenshotOne — 10年勤めたエンジニアが辞めて作った「URLを画像にするだけ」の地味なAPIが、build in publicとSEOだけで3年かけてARR約$200K〜$300Kへ

背景とプロダクト

ScreenshotOneは、WebページのURLを渡すと1枚の画像(またはPDF/HTML)を返す、開発者向けのスクリーンショットAPIだ。OGP画像の自動生成、Webサイトのサムネイル、監視・アーカイブ、営業資料の自動化などに使われる。ユーザーは一般消費者ではなく『他の開発者・企業』——いわば“ツルハシ”を売る側の商売である。

作ったのはDmytro Krasun。10年ほどサーバーサイドの開発者として働いたのち独立し、2022年5月29日に公開した(着想の記録は2022年1月、本人が掲げた『1001プロジェクトを作る』計画の2本目=“Project 0002/1001”として残っている)。派手なバイラルとは無縁で、本人いわく“calm business(穏やかなビジネス)”を、外部資金ゼロ・ソロで淡々と運営している。

ただし最初から順風満帆だったわけではない。ローンチから約1年後の2022年11月時点でMRRはわずか$141。本人は当時、人生の選択を疑ったと書いている。そこから諦めずに機能とドキュメントを積み上げ、$2.5K→$10K MRRと登っていった。2025年4月には公式ブログで『ARR $200K・有料顧客400社超』を公表。2025年8月には約$21.6K MRR、直近はARR約$300K・有料650社という数字も出ている(この上振れ分は二次情報)。

技術的には、ヘッドレスブラウザ運用の面倒(スケール・レンダリングの再現性・広告/Cookieバナー除去など)を肩代わりするのが価値の中心。料金は無料枠(月100枚)から始まり、Basic $17(2,000枚)、Growth $79(10,000枚)、上位$259(50,000枚)と、使った分だけスケールする従量的サブスク設計だ。

再現できる手順

1. 1バズを狙えないなら“構造的に堅い退屈な問題”を選ぶ(スクショAPI=多くの開発者が自作して保守に疲れる=低チャーン)
2. 2複利は序盤ほど平ら=1年目の月$141に耐える設計(生活費・期待値)を先に作り、諦めずに機能とドキュメントを積む
3. 3build in publicを“規律装置”として使う(収益公開=締切+信頼+開発者コミュニティでの被リンク。発信のオン/オフも設計する)
4. 4開発者の検索意図をSEOで刈り取る(言語別実装ガイド/競合比較/ユースケースを量産→公式ドキュメントへ流す。広告費ゼロ)
5. 5従量サブスク設計(無料枠→$17〜$259)で単価より導入と利用量拡大を優先=少数の有料顧客でもARRが積む
6. 6ソロは成長速度より持続可能性(calm business)を最適化する=VC・採用を取らず1人で回せる範囲に設計する

深掘り分析

【深掘り】40件超あるこのDBの大半は、TikTok/Instagramで一気に燃える消費者アプリだ。ScreenshotOneはその真逆——『他の開発者に売る退屈なAPI』を、build in publicとSEOという2本の足だけで、3年かけて複利で伸ばした“地味さの勝ち筋”である。日本のエンジニアにとって最も再現性が高いタイプの事例として分解する。

■ ① 題材選び:バズらないが“構造的に堅い”退屈な問題を選ぶ スクショAPIは決して新しくもセクシーでもない。競合も存在する。だがDmytroが選んだのは『多くの開発者が一度は自作し、保守に疲れて外注したくなる』構造的needだ。ここが重要で、需要が流行に依存しないためチャーンが低く、一度組み込まれると剥がれにくい(APIは製品の内部に埋まる)。派手なバイラルは起こせないが、その代わり“燃えて消える”リスクも無い。DBの多くの消費者アプリが抱える『バイラルが止まると失速する』脆さと対照的だ。

■ ② 最初の1年は複利が平ら=“諦めない”が最大の技術 ローンチ後13ヶ月の2022年11月、MRRはたった$141だった。本人は人生の選択を疑ったと明かしている。彼のポッドキャスト出演回のタイトルがそのまま『The Art of Not Giving Up(諦めない技術)』であることが象徴的だ。複利は序盤ほど平らに見える——SEOの被リンクもドメイン評価も、build in publicの信頼も、最初は数字に出ない。ここで多くの個人開発者が畳む。彼は畳まず、機能とドキュメントを積み続けた。1年目を耐えたことが、その後の$10K→$20K+への“カーブ”の前提になった。

■ ③ 集客の1本目:build in public を“規律装置”として使う DmytroはX(旧Twitter)とThreadsで収益や進捗を継続的に公開している。build in publicの効用は3つ:(1)公開が自分への締切=規律になる (2)数字を出す個人は信頼されやすく、開発者コミュニティで口コミ・被リンクが生まれる (3)潜在顧客(他の開発者)がそのまま観客になる。象徴的なのは彼の『$5K+ MRRに達するまでTwitterをやめる』という逆説的な投稿——公開のしすぎで手が止まる時期には、あえて発信を断ってプロダクトに集中した。build in publicは“承認欲求の垂れ流し”ではなく、オン/オフを設計する道具として扱っている。

■ ④ 集客の2本目:開発者の検索意図をSEOで根こそぎ取る もう1本の足が技術SEOだ。開発者は課題に当たると必ず検索する——「take screenshot with Go」「puppeteer screenshot API」「website thumbnail API」等。Dmytroは言語別(Go/Python/Node…)の実装ガイド、競合比較、ユースケース解説を大量に書き、これらロングテールの高意図キーワードを1本ずつ押さえた。ブログの一部は本人名義のMedium/技術記事から、公式ドキュメントへと需要を流し込む。広告費ゼロでCACを限りなく下げるこの型は、退屈だが複利で効く。stagetimer(#82)の“ドキュメント主導SEO”と同系だが、あちらがイベント業界の一機能なのに対し、本件は『開発者が書くコードの検索語』そのものを取りにいく点が異なる。

■ ⑤ ソロ・calm business:持続可能性を最優先に設計する DmytroはVCを取らず、従業員を雇わず、1人で回している。新生児を育てながら夜中にコードを書いていた時期もあった(Medium『Midnight Code』)。派手な成長を追わず“穏やかに続ける”ことを明確な目的に据えているため、価格も無料枠→従量サブスク(月$17〜$259)と、単価より導入のしやすさとスケール余地を優先。B2B APIは1社が使い込むほど利用量=請求額が自然に増えるので、少数の有料顧客(400〜650社)でもARR $200K〜$300Kが成立する。18ヶ月ロケット型の消費者アプリとは真逆の、3年スパンの遅い複利だ。

■ 日本の個人開発者への示唆 この事例の学びは明快だ。(a)バズを狙えないなら“構造的に堅い退屈な問題”を選ぶ。(b)複利は序盤ほど平らなので、1年目の$141に耐える設計(生活費・期待値)を先に作る。(c)集客はbuild in public(規律+信頼+被リンク)とSEO(検索意図の刈り取り)の2本足でCACをゼロに寄せる。(d)ソロなら成長速度より持続可能性を最適化する。英語圏の派手なexit事例より、むしろ多くの日本人エンジニアが“今日から真似できる”型である。