Vibe codingでアプリデモを作ったが、本物の製品にする方法が分からないとき
見た目の良いprototypeを、本物のユーザーが使えるものに変える90日実行計画。
Vibe codingは、最初のバージョンを不思議なほど近く感じさせます。
アプリを説明する。インターフェースが現れる。いくつかのflowが動く。デモは、数年前なら週末で作れなかったものより良く見えます。
そして難しい部分が始まります。
自分が操作しているときはアプリが動きます。でも見知らぬ人が来ると、そうはいきません。
ログインflowは荒い。データモデルは脆い。オンボーディングがない。エラーは分かりにくい。activationは誰も追っていない。フィードバックはあちこちのチャットに散らばっている。landing pageは言いすぎるか、言わなすぎる。launchはいつも、もう1回のcleanupを待っています。
これがpost-demo gapです。
デモは存在します。でも製品の周りにまだシステムがありません。
Vibe-codedアプリがデモ後に止まる理由
危険なのは、アプリが生きているように見えることです。
そのため、製品を使えるものにする退屈な仕事を避けながら、見える機能を追加し続けやすくなります。
よくある次のタスクは、こう聞こえます:
- UIをきれいにする、
- settings pageを追加する、
- dashboardを改善する、
- もう1つAI機能を追加する、
- landing pageを書き直す、
- authは後で直す、
- 次のバージョンの後にlaunchする。
その一部は重要かもしれません。
でも本当の問いはもっとシンプルです:
本物のユーザーが来て、約束を理解し、価値に到達し、混乱から回復し、あなたにシグナルを返せますか？
そうでないなら、アプリはまだデモです。
ミニ診断
アプリデモをvibe codingで作ったが本物にする方法が分からないなら、どのgapが移行を止めているかを確認しましょう。
1. 製品の約束がまだぼやけている
デモは印象的でも、明確でないことがあります。
ユーザーはアプリが存在することには関心がありません。何を助けてくれるかに関心があります。
約束を1文で書きます:
これは[具体的なユーザー]が[具体的な仕事]をして、[具体的な成果]を得るのを助ける。
この文が曖昧なら、オンボーディング、landing page、機能判断はすべてドリフトします。
聞いてください:
- この最初のバージョンは本当に誰のためですか？
- その人はすでにどんな痛みを解こうとしていますか？
- 最初のセッションでどんな成果を感じるべきですか？
- その成果から注意をそらすため、何を取り除くべきですか？
最初のバージョンは、夢全体を説明する必要はありません。
最初の約束を明らかにする必要があります。
2. First-run valueが自分の説明に依存している
private demoにはたいてい語り手がいます。
あなたはどこをクリックするか知っています。どのinputが動くか知っています。未完成部分が何を意味するかも知っています。
本物のユーザーは知りません。
だからfirst-run flowは、coachingなしでテストする必要があります。
誰かが試すのを見ます。説明しません。どこで止まり、読み違え、飛ばし、混乱するかを観察します。
探しているのは、first-run value pathです:
- landing promise、
- signupまたはentry、
- 最初のinput、
- 最初の有用なoutput、
- 次のステップ、
- 戻ってくる理由。
ユーザーがあなたなしで価値に到達できないなら、次のマイルストーンは別の機能ではありません。
First-run clarityです。
3. Launch basicsをcleanupとして扱っている
退屈な仕事が、デモを製品に変えます。
それには次が含まれます:
- 壊れないauth、
- 実際の使用に耐えるデータ、
- empty states、
- error states、
- loading states、
- analytics、
- feedback capture、
- support path、
- 基本的なdocsまたはhelp text、
- 次のユーザーを招待する明確な方法。
どれも新しいAI機能ほど満足感はありません。
でもそれがないと、新しいユーザーは全員、手動サポートセッションになります。
アプリは、機能が多いから本物なのではありません。
見知らぬ人が使えて、次に何を改善すべきかを教えてくれるとき、本物になります。
4. Distributionがbuild planにない
Vibe-codedアプリは奇妙な錯覚を生みます。デモが速かったのだから、audienceも速く現れるはずだという錯覚です。
普通はそうなりません。
Distributionは週次計画の一部にする必要があります:
- use-case pageを1つ公開する、
- 具体的なデモを1つ投稿する、
- 具体的な5人を招待する、
- コミュニティで本物の問題質問をする、
- early testerにフォローアップする、
- objectionを書き留める、
- 人々が実際に使う言葉でpromiseを改善する。
今週、誰も新しくアプリを見ないなら、今週アプリはより本物になれません。
シンプルな90日vibe-codedアプリ実行計画
最初の構造として使ってください。
成果
90日で、アプリデモを、明確なユーザーグループが1つのfirst-session outcomeに到達できる使える製品に変え、本物のactivation、feedback、retentionシグナルで次に何を作るかを決める。
マイルストーン1: First-session outcomeを定義する
ユーザー1つと成果1つを選びます。
例:
indie builderが散らかったアプリアイデアを、今週動けるlaunch checklistに変えられるようにする。
次に、その成果に対してアプリを点検します。
最初のユーザーが最初の成果に到達する助けにならないものは、後回し、非表示、または削除です。
マイルストーン2: 製品gapを閉じる
新機能を追加する前に、launch blockerを選びます。
追うべきblocker:
- オンボーディングの混乱、
- authまたはaccount問題、
- 壊れたデータ状態、
- missing empty states、
- 不明確なエラー、
- analyticsなし、
- feedback captureなし、
- support pathなし、
- distribution artifactなし。
すべてを一度に解決しないでください。
次の本物のユーザーを最も止めている1つを閉じます。
マイルストーン3: Real-user loopを回す
毎週、同じループを回します:
- 小さな本物のユーザー群を招待または到達する、
- first-run pathを観察または測定する、
- 混乱と離脱を記録する、
- 1つの修正を出荷する、
- シグナルから次のアクションを決める。
目的は、アプリを完成しているように見せることではありません。
現実から学べるようにすることです。
週次実行ループ
これを週1回実行します:
- 改善したいユーザー成果を1つ選ぶ。
- 本物のfirst-run attemptを1つ観察または点検する。
- オンボーディング、信頼性、analytics、フィードバック、distribution gapのどれか1つを閉じる。
- 見えるartifactを1つ出荷する、または小さなaudienceを招待する。
- 機能への興奮ではなく、activationまたはfeedbackから次のアクションを選ぶ。
こうしてデモは製品になります。
1回のheroic launchではありません。
次の見知らぬユーザーが価値を得やすくなる反復ループです。
計画に変える
アプリデモは動くのに、まだ本物に感じられないなら、別の機能追加から始めないでください。
痛みから始めます:
Vibe codingでアプリデモを作ったが、本物の製品にする方法が分からない。
それを90日実行システムに変えます: 1つのfirst-session outcome、短いlaunch blockerリスト、週次real-userシグナル、distribution action、次のステップ。
90日実行計画ジェネレーターで最初のバージョンを作ってください。プレビューが役に立つなら、X18の生きたミッションとして保存し、デモ後もアプリが動き続けるようにします。
