SECTION 01
スタック選定の判断軸は3つに絞れる
個人開発の技術スタックを選ぶとき、選択肢の多さに手が止まる方は多いと思います。判断軸を3つに絞ることで、迷う時間を大幅に減らせます。
1つ目は同じ構成を繰り返せるかという軸です。毎回違うスタックを試すと、立ち上げのたびに学習コストが発生して完走率が下がります。
2つ目は初期は最小構成で出して、あとから足せるかです。最初からフル装備で設計すると、リリース前に息切れしてプロジェクトが止まります。
3つ目は課金が発生するタイミングを自分で把握できるかです。無料枠の境界がわかりにくいサービスを選ぶと、想定外のコストに悩まされることになります。
この3つを意識するだけで、技術選定の議論が「何が流行っているか」から「自分が一人で回せるか」に変わります。個人開発では、使える技術より続けられる技術の方がはるかに重要です。
SECTION 02
私が採用している技術スタック全体図
私はこれまで個人開発でサービスを40個以上作ってきましたが、その試行の中で今ほぼ固定して使っている構成があります。
Web側はNext.jsでフロントもバックエンドも完結させる構成です。APIルートまで一つのプロジェクトに収まるので、リポジトリを分ける管理コストがなくなります。
アプリ側はReact NativeとExpoの組み合わせです。Expoと組み合わせると開発体験が快適で、iOSとAndroidの両方に一つのコードベースから出せます。
サービス層の構成は以下のとおりです。
- ホスティング: Vercel
- データベース: Neon（Postgres）
- 認証: Neon Auth
- メール: Resend
- ストレージ: Cloudflare R2
- 決済: Stripe
- モバイル課金: RevenueCat
メール配信、ストレージ、決済も最初から組み込んでいます。今はAIを活用することで実装の難易度が大きく下がっているため、フルで入れても負担は少ないです。
この組み合わせに落ち着いた理由は、CLIが使えてシンプルなサービスを好んで選んでいるからです。管理画面が複雑なサービスは一人で運用するときにストレスになりますし、後述するAIエージェントとの相性にも影響します。
さらに、この構成でよく開発するため、これらをまとめたボイラープレートを作りました。
StartPack
SaaS、AIツール、Webアプリを素早くNext.jsで構築できます。認証・決済・お問い合わせ・データベースまで実装済みのスタートパックです。
SECTION 03
初期構成はここまで絞る——まず出すための最小スタック
新しいサービスを作り始めるとき、最初から構成を重くしないのが自分の基本方針です。初期に積み上げすぎると完走できないという感覚は、多くの失敗経験から身についたものです。
まず動くものを出すために使うのはVercel + Neon + Neon Authだけです。この3つがあればWebアプリとしての最低限——ページ表示、データ保存、ユーザー認証——が揃います。
特に認証は個人開発者が最も詰まるポイントです。自前で実装すると想像以上に時間を取られますし、セキュリティの考慮事項も多いため、ここを素早く片付けられるかが完走率に直結します。
認証まわりで自分がおすすめしているのはNeon Authです。データベースと認証を同じサービスで扱えるため、初期の接続設定やデプロイの手順がシンプルになります。認証のためだけに別サービスを契約して管理画面を行き来する必要がなくなるので、一人で回す構成としては理想的です。
メール配信、ストレージ、決済といった機能も、今はAIの力を借りれば組み込みのハードルがかなり下がっています。以前なら「出してから判断」としていた部分も、最初からフルで入れておいて問題ないケースが増えました。
この「最小構成で素早く出す」感覚を持ちつつ、AIで実装コストを圧縮できる部分は最初から盛り込む。このバランスが、一人で回し続けるための核になっています。作り切れないサービスに費やした時間は戻ってきません。
SECTION 04
フロントエンド：Tailwind CSS + shadcn/uiに固定して迷いを消す
フロントエンドのスタイリングはTailwind CSSとshadcn/uiの組み合わせに固定しています。毎回CSSライブラリを比較検討する時間がなくなり、作り始めの速度が上がります。
shadcn/uiの特徴はコンポーネントのコードが自分のプロジェクトにコピーされる点です。ライブラリに依存するのではなく手元にコードがあるので、カスタマイズの自由度が高く、アップデートで壊れるリスクも低いです。
フロントエンド選定で自分が重視している要素は以下です。
- 学習コストの再発を防げるか: 毎回違うUI構成にすると、立ち上げが遅くなる
- AIとの相性が良いか: 利用者が多い技術ほどAIの出力精度が高い
- コンポーネントの再利用が効くか: 過去のプロジェクトから持ってこられる構成が理想
以前は案件ごとにUIフレームワークを変えていた時期もありました。その都度ドキュメントを読み直す手間が積み重なり、結果的に構成を揃えた方が速いという結論に至っています。
「選択肢が多い＝良い」と考えがちですが、個人開発においては選択肢を減らすこと自体が生産性です。迷っている時間は一行もコードを書いていません。
SECTION 05
データベースとインフラ：NeonとCloudflareを軸にした構成
データベースはNeon（Postgres）を標準にしています。PostgreSQLベースなので学習資産がそのまま使えますし、サーバーレスで動作するためスケールの管理を意識しなくて済みます。
Neonを選んでいる理由のひとつはコスト構造の透明さです。個人開発では無料枠の範囲内で始めて、ユーザーが増えた段階で有料プランに移行するのが自然な流れなので、どこで課金が発生するかが明確なサービスを選ぶことが重要です。
インフラ側ではCloudflareを組み合わせて使う構成が定着しています。Cloudflareは無料で使える範囲が大きく、個人開発者にとって非常にフレンドリーです。
たとえば自分のプロジェクト「KingCoding」ではCloudflare Tunnelを採用しました。Vercelでフロント側をさばきながら、インフラ側はCloudflareで組むパターンです。
この構成が個人開発に向いている理由をまとめると以下のとおりです。
- Vercelでデプロイの運用負荷をゼロに近づけられる: git pushだけで本番反映される
- Cloudflare R2で画像やファイルの配信コストを抑えられる: エグレス料金がかからない
- Neonでデータベースの起動・停止を気にしなくてよい: サーバーレスなのでアイドル時のコストが低い
一人で長期運用することを前提にすると、サービスの数を増やさない構成が重要です。管理画面を行き来する手間は、サービスが増えるほど指数的に膨らみます。
SECTION 06
モバイル課金：RevenueCatでiOS/Androidを一元管理する
モバイルアプリで課金機能を入れるときはRevenueCatを使っています。iOSとAndroidの両プラットフォームに対応した課金基盤を一つのサービスで一元管理できるのが最大の理由です。
プラットフォームごとに課金の実装を分けると、後の運用が煩雑になります。レシート検証やサブスクリプションの状態管理をそれぞれ別に書くのは、一人で保守するには現実的ではないです。
自分が実際に踏んでいるフローは以下の順序です。
- ストアに申請: App Store / Google Playそれぞれにアプリを提出
- クローズドテスト: 限定公開で課金フローを確認
- 実機で決済確認: テスト環境での購入・復元・解約を一通り試す
このフローを最初から固定しておくことで、新しいアプリを出すたびに手順を思い出す必要がなくなります。個人開発では手順のテンプレ化がそのまま速度になります。
App StoreやGoogle Playへの申請も毎度大変なので、PRスクリーンショットを作成できるサービスを作りました。
STOPRO
スクショをアップするだけで、ストア掲載用デザインをAIが自動生成します。iOS・Android両対応です。
課金まわりは審査のリジェクト要因にもなりやすい領域です。実績のあるサービスに寄せて実装の不確実性を減らすことが、一人で出し続けるための現実的な判断です。
SECTION 07
AI時代のスタック選定——開発速度に直結する新しい軸
技術スタックの選定基準に、「AIが扱いやすいか」という新しい軸が加わっています。自分は開発フロー全体にAIを深く組み込んでいて、この軸がスタック選びに直接影響しています。
AIの出力精度が高い技術には共通する特徴があります。型情報が充実していること、ドキュメントが整備されていること、コミュニティの規模が大きいことです。この条件に合う技術を選ぶと、AIによるコード生成やリファクタリングの精度が目に見えて変わります。
具体的にAIとの相性が良い選定基準は以下のとおりです。
- TypeScript + Next.js: 型情報が豊富でAIが正確なコードを出しやすい
- Tailwind CSS: クラス名ベースなのでAIがスタイルを指定しやすい
- PostgreSQL: 歴史が長くAIの学習データに十分含まれている
逆に、リリースから日が浅い技術はAIの回答精度が落ちるという実務感覚があります。最新のフレームワークに飛びつきたい気持ちはありますが、AIが正確に扱えない技術を選ぶと、結局は自分で調べる時間が増えてしまいます。
もうひとつ重要なのがCLIベースのサービスを選ぶ理由です。AIエージェントがコマンドを実行してデプロイや設定変更を行える構成にしておくと、開発フローの自動化がぐっと進みます。管理画面をクリックする操作はAIには任せられません。
AI支援エディタを開発フロー全体に組み込んでからは、生産性が根本的に変わったという実感があります。スタック選びとAIの活用は、今や切り離せない関係にあります。
SECTION 08
スタック選びでよくある失敗パターン
自分自身が経験してきた失敗も含めて、個人開発のスタック選びで繰り返されるパターンを整理します。同じ落とし穴に落ちる前に知っておく価値がある話です。
最もよくあるのは興味優先で新技術を選んで、機能要件を満たせなかったというケースです。試したい技術と作りたいものが噛み合わないまま始めると、途中で「この技術ではやりたいことができない」と気づいて手が止まります。
次に多いのが毎回スタックを変えてしまうパターンです。新しいプロジェクトのたびに違う技術を選ぶと楽しいのですが、立ち上げのたびに学習コストが発生して開発速度が出ません。
よくある失敗パターンをまとめると以下のとおりです。
- 興味で選ぶ: 学習目的と開発目的がごちゃ混ぜになる
- 毎回変える: 知識が蓄積されず、いつまでも初学者の速度
- 重くしすぎる: 構成が複雑になりリリース前に止まる
- コストを把握していない: 無料枠の境界を超えて想定外の請求が来る
構成を重くしすぎる失敗は完走率に直結します。マイクロサービス構成にしたり、キャッシュ層を最初から入れたりすると、個人では運用しきれずに放置されるサービスが増えるだけです。
無料枠の想定外課金も見過ごせません。どのサービスのどの操作で課金が発生するかを事前に把握していないと、ユーザーが増えた瞬間に維持費が跳ね上がります。スタックを選ぶ段階でコスト構造を確認しておくことが、一人で続けるための前提条件です。
SECTION 09
同じ構成を繰り返しながら進化させるという考え方
スタックを固定すると聞くと「成長が止まるのでは」と感じるかもしれません。しかし実際には同じ構成を繰り返すことで、技術の深い部分に触れる余裕が生まれます。
新しいスタックを毎回一から学ぶと、表面的な使い方だけで終わりがちです。同じ技術を繰り返し使うからこそ、エッジケースやパフォーマンスの勘所が身につきます。それが結果的に開発速度を上げてくれます。
構成を固定しつつ進化させるために意識していることは以下です。
- コアは変えない: Next.js + Neon + Vercelの軸はそのまま維持する
- 周辺を入れ替える: メール配信やストレージなど、交換しやすい層で新しいサービスを試す
- 知見を横展開する: ひとつのプロジェクトで得た改善を他のプロジェクトにも反映する
「同じ構成を繰り返せるか」は最初に挙げた判断軸のひとつです。繰り返しに耐える構成かどうかは、実際に複数のプロジェクトで使ってみないと分かりません。だからこそ、早い段階で自分の定番を持っておくことに価値があります。
技術選定に正解はありませんが、一人で回せるかどうかには明確な線引きがあります。完走できなければどんなに良い技術でも意味がありません。まずは最小構成で出して、手応えがあればそこから足していく。このサイクルが個人開発を続けるための土台になります。
