個人開発プロダクトのリリースまでにやった全てのこと
個人開発でプロダクトをリリースするまでに必要な全工程を、技術選定からマーケティングまで実体験ベースで解説する。
個人開発のリリースとは何か
個人開発のリリースとは、アイデアを形にして実際にユーザーが使える状態まで持っていく一連のプロセスのことである。コードを書くだけではない。技術選定、テスト、インフラ構築、マーケティング準備まで含めた全体設計が必要だ。
私は2026年3月末に開業届を出し、R3O Worksという屋号で個人事業を始めた。最初のプロダクトShutter（ノートアプリ）のリリース予定は4月27日。開業から1ヶ月足らずでプロダクトを世に出す。この記事では、そこに至るまでにやった全てのことを振り返る。
なぜShutterを作ろうと思ったのか
きっかけはシンプルだ。既存のノートアプリに満足できなかった。
NotionやObsidianは高機能だが、起動が遅い。メモを開くまでに数秒かかるだけで、思考の流れが途切れる。「もっと速くて、もっとシンプルなノートアプリがほしい」という自分自身の不満がShutterの出発点だった。
R3O Worksのミッションは「こっちの方がもっといい！」を作ること。破壊的なイノベーションではなく、既存のものより少しだけ良い代替を提供する。Shutterはその第一歩だ。
詳しくは「なぜ今、新しいノートアプリを作るのか」で書いている。
どんな技術スタックを選んだのか
技術選定の基準は3つ。速さ、シンプルさ、コストゼロだ。
| カテゴリ | 技術 | 選定理由 |
|---|---|---|
| フレームワーク | React + Vite | 高速なHMR、軽量バンドル |
| 型システム | TypeScript | 型安全性と保守性 |
| スタイリング | Tailwind CSS v4 | ユーティリティファースト、ビルド時最適化 |
| エディタ | Tiptap (ProseMirror) | カスタマイズ性の高いリッチテキスト |
| データ保存 | IndexedDB / Dexie.js | ローカルファースト、サーバー不要 |
| アイコン | Lucide React | 軽量で統一感のあるアイコンセット |
| テスト | Vitest + fake-indexeddb | 高速なユニットテスト |
| CI/CD | GitHub Actions + FTP | 自動デプロイ、インフラ費用ゼロ |
特に重要なのはデータ保存にIndexedDBを選んだことだ。すべてのデータをブラウザのローカルに保存するため、サーバーが不要になる。これはインフラ費用ゼロを実現する鍵であり、同時にユーザーのプライバシーを完全に守る設計でもある。
AIネイティブ開発のワークフローはどうなっているか
私の開発スタイルは「AIネイティブ」だ。Claude CodeとCursorを中心に据え、設計からコーディング、テスト、デプロイまでAIと協働する。
具体的なワークフローは以下の通りだ。
- UIモック作成: Pencil MCPでワイヤーフレームを描く
- モック確認: 構造データを取得して設計意図を検証する
- コード変換: モックから1コンポーネントずつ実装する
- テスト作成: Vitestで振る舞いベースのテストを書く
- 品質チェック: バグ検出、セキュリティレビュー、リファクタを実行する
- コミット: コンベンショナルコミット形式で変更を記録する
このワークフローの詳細は「AIネイティブ開発とは何か」で解説している。
ポイントは、AIに丸投げしないことだ。設計判断は人間が行い、AIには実装とチェックを任せる。バイブコーディングで本番プロダクトを作るで書いた通り、本番品質のプロダクトを作るにはAIの出力を検証する目が必要である。
テストと品質管理はどうしているか
個人開発だからといってテストを省略しない。むしろ一人だからこそ、テストが安全網になる。
テスト戦略
- ユニットテスト: Vitest + fake-indexeddb で49テスト全パス
- 対象範囲: ユーティリティ関数4ファイル + DB操作
- テスト原則: 振る舞いベース（実装詳細に結合しない）
- テスト間の独立性: 順序非依存で実行可能
パフォーマンスKPI
| 指標 | 目標 | 実績 |
|---|---|---|
| ウォーム起動（入力可能まで） | 200ms以内 | 約200ms（達成） |
| コールド起動 | 500ms以内 | 343ms（初期620msから改善） |
| 自動保存 | 300-500ms debounce | 実装済み |
パフォーマンスは「体感の速さ」がコアバリューであるShutterにとって最重要のKPIだ。計測に基づく最適化を徹底し、コールド起動を620msから343msまで改善した。
インフラ費用ゼロでどうやって運用するのか
個人開発で最も大きな課題の一つがインフラ費用だ。収益が出る前にランニングコストが発生すると、プロダクトの寿命を縮める。
Shutterはこの問題をアーキテクチャレベルで解決した。
- データ保存: IndexedDBによるローカル保存（サーバー不要）
- ホスティング: 共有レンタルサーバー（既に公式サイトで契約済み、追加費用なし）
- CI/CD: GitHub Actions（無料枠内） + FTPデプロイ
- SSL: レンタルサーバー付属の無料SSL証明書
- ドメイン: r3o.works（公式サイトと共有）
結果として、Shutterの追加インフラ費用はゼロだ。既存の公式サイトのインフラをそのまま活用している。
マーケティングの準備は何をしたか
エンジニアにとって苦手な領域がマーケティングだ。私自身「作れるが売り方を知らない」という課題を感じている。だからこそ、リリース前からマーケティング準備を並行して進めた。
やったこと
- 公式サイト構築: Hugo + 日英対応、SEO対策済み
- プロダクトページ作成: Shutterの紹介ページを日英で公開
- ブログ開設: 技術記事と運営記録を定期更新
- SEO対策: メタデータ、構造化データ（JSON-LD）、内部リンク設計
- SNS運用設計: X（Twitter）でのBuild in Public戦略
マーケティングの学びは「個人開発のマーケティングをゼロから学ぶ」にまとめている。予算ゼロの状態でも、コンテンツとSEOでオーガニック流入を積み上げることは可能だ。
リリース前チェックリストはどうなっているか
最後に、リリース前にチェックすべき項目をまとめる。Shutterで実際に使っているチェックリストだ。
プロダクト
- コア機能が動作する
- ユニットテストが全パスする
- E2Eテストが完了する
- パフォーマンスKPIを達成している
- クリティカルなバグがない
インフラ
- ビルドが成功する
- デプロイパイプラインが動作する
- SSL証明書が有効である
- 本番環境で動作確認済み
マーケティング
- プロダクトページが公開されている
- メタデータ（OGP、Twitter Card）が設定されている
- リリース告知の投稿文が準備されている
- ランディング先のURLが確定している
法務
- 特定商取引法に基づく表記がある
- プライバシーポリシーが公開されている
- 利用規約が公開されている
まとめ
個人開発のリリースは、コードを書くことのほんの一部にすぎない。アイデアの検証、技術選定、開発プロセスの構築、テスト、インフラ設計、マーケティング準備、法務対応。一人で全てをやる必要がある。
だが、AIネイティブな開発スタイルとゼロコストアーキテクチャを組み合わせれば、個人でも本番品質のプロダクトを作ってリリースすることは十分に可能だ。Shutterのリリース日は4月27日。エンジニアがソロファウンダーとして起業した話で書いた挑戦は、まだ始まったばかりである。