Lovableの選び方｜Web試作から公開・保守へ進む条件

利用者の仕事から要件を書く

最初の要件には利用者、入力、保存する情報、完了後に見える結果を含めます。例えば社内申請なら、申請者と承認者で見える情報や操作が異なります。架空の情報を使い、申請、一覧、詳細、訂正の流れが成立する範囲から始めます。画面数を増やす前に、空欄や失敗した保存の扱いを決めてください。見た目の希望だけでは、認証や保存の前提は伝わりません。必要な条件を短く書き、後で同じ条件から確認できる形へ残すことが、制作と保守の両方に役立ちます。

二回目の変更で構造を見る

一度画面ができたら、任意項目を一つ追加し、既存データを読み直します。次に、一般利用者が変更できない項目を定義し、直接URLを開いた場合も含めて確認します。新しい画面を別に作り直せることより、元の機能を保って修正できることが継続利用の判断材料です。変更理由、関係するコード、未確認の条件を説明してもらい、分からない点は保守する人へ渡します。認証が必要なサービスでは、ボタンを隠せたことを権限の確認として扱わないでください。

• Lovableの料金とクレジット｜共有残高・上限・解約を確認

共有残高と用途を分けて予算にする

現在の公式案内では、ワークスペースの残高を開発、Cloud、アプリ内AIに使う構成です。用途別の記録は必要ですが、必ず三つの独立した有料残高があるという意味ではありません。メンバーが増えると席数だけでなく共有残高の消費が変わります。利用上限や通知を確認し、月の開発作業が少ない場合でも公開アプリの消費を見てください。有料開始額はここでは確定していないため、公式契約画面の金額と期間を採用し、別プランのクレジット数を同じ価値として割り算しません。

架空の例：申請の訂正と閲覧権限

架空の備品申請で、申請者は自分の申請だけを訂正でき、承認者は状態を変更できるとします。利用者AとB、承認者の三者で、一覧、詳細、訂正、再読み込みを確認します。入力項目を追加した後にも同じ確認を行い、既存の申請が消えないことを見ます。通知を使う場合は本物の宛先へ送らず検証用の設定を使ってください。この例は実測した成功率ではなく、試作品を業務へ持ち込む前に、保存と権限の前提を確かめる課題です。

• LovableとBoltを比較｜Webアプリの修正・費用・引き継ぎ

Git同期で持ち出せる範囲

公式のGitHub連携はコードの書き出しと双方向同期を案内しています。別の開発者がコードを確認し、通常の開発環境で修正する経路として役立ちます。ただし、DBの中身、認証、秘密情報、外部API、ドメインまで一度に移ることを示す機能ではありません。移行を想定するなら、コードと各サービスを別に一覧化し、見本データで移行先を起動します。必要な変数名は残しても秘密値をGitへ入れず、元の画面がなくても次の人が環境を用意できるかを確認してください。

解約とサービスの終了は分ける

公式のWeb契約手順では、プラン管理からFreeへ下げる操作が有料契約の取消に当たり、現在の請求期間の終了後に適用されます。残るクレジットには種類ごとの条件があるため、解約前に利用可能期間を確認してください。公開アプリを止めたい場合、プランを下げたことだけで停止したとは判断せず、公開状態を別に確認します。移行では次の担当者が起動と小修正を行える状態を作り、必要なデータを保存してから契約と接続を整理すると、運営の継続を具体的に判断できます。 障害時に保存データをどこから読み出し、誰が復旧を判断するかも、運営の担当者が記録します。

• Lovableの代替候補｜コードを引き継いで育てるアプリ開発