「このサービス、流行ったら地獄じゃないか？」
前回まで、GoogleMapと写真を組み合わせた
“旅ログ自動生成MAPサービス”
を作っていました。
正直、アイデアとしてはかなり好きでした。
旅行した場所が線で繋がって、
写真が浮かび上がって、
自分だけの旅の歴史がMAP上に残っていく。
ロマンはある。
かなりある。
でも、開発を進めている途中で、
あることに気付きました。
「これ、ユーザー増えたら死ぬのでは？」
ということに。
原因はシンプルで、
“画像”です。
旅アプリって、
想像以上に画像を扱います。
しかも旅行写真って、
1枚数KBの世界じゃない。
普通に数MB。
さらにユーザーは、
1回の旅行で何十枚もアップロードする。
つまり、
- ストレージ費用
- 通信量
- 画像圧縮
- 表示最適化
- キャッシュ
- CDN
- レスポンス速度
- モバイル回線対応
など、
急に「夢のアプリ」から
「インフラとの戦い」
が始まる。
ここでかなり実感したのが、
個人開発は「作る力」だけでは足りない
ということでした。
Codexを使うと、
正直かなりの速度で形になります。
UIも作れる。
機能も生える。
Firebaseも繋がる。
だから一瞬、
「これ、全部いけるのでは？」
という感覚になる。
でも実際は、
“作れた” と “運営できる” は別でした。
特に収益化を目指すなら、
- 維持費はいくらか
- ユーザー増加に耐えられるか
- 無料ユーザーで赤字化しないか
- サーバー代が先に死なないか
この視点がかなり重要だと感じました。
開発者っぽく言うと、
最近は「機能実装」よりも
“ランニングコスト設計”
の方が気になっています。
夢を作るというより、
「この構成、月額いくらで耐える？」
を考え始めた。
かなり現実を見始めています。
なので今回は、
一旦ロマン全開のMAPサービスから離れて、
もっと低コストで回せる構成を考え直していきます。
多分これが、
「個人開発が楽しい時期」から
「運営を考え始める時期」
への分岐点なんだと思います。