個人開発の最初の価格を決める

価格は、正解を一度で当てる数字ではありません。誰にどんな価値を、どの単位で届けるかという仮説です。最初の価格は、説明でき、運用でき、反応を見て見直せる形にします。

何に対して支払うのかを書く

機能数ではなく、利用者が得る結果を一文にします。

毎月二時間かかる集計を、確認を含めて十五分で終えられる。

時間の短縮だけでなく、ミスの減少、判断のしやすさ、安心して継続できることも価値になります。ただし、まだ確かめていない効果を断定しません。利用者への聞き取りや小さな販売で、どの結果に支払い意思があるかを確かめます。

Stripeのドキュメントでは、定額、利用者単位、段階制、従量制などの継続課金モデルが整理されています。個人開発の初期は、細かな選択肢を増やすほど説明、実装、問い合わせ対応が複雑になります。

候補を次の観点で比べます。

毎月使う価値がなければ、無理に定期課金へしません。買い切り、期間利用、作業ごとの料金なども含めて、利用の実態に合う単位を選びます。

売上から差し引かれるものを先に並べます。

この合計を下回る価格は、利用者が増えるほど維持を難しくします。税務・法務の扱いは地域や販売方法で変わるため、不確かなまま断定せず、必要に応じて専門家や公式情報を確認します。

初回は、基本プランを一つに絞ると反応を読みやすくなります。価格ページには、対象となる人、含まれるもの、含まれないもの、支払い周期、解約や返金の扱いを明示します。

公開後は、閲覧数だけでなく、購入前の質問、購入しなかった理由、利用継続の状況を記録します。値下げだけを改善策にせず、価値の伝え方、対象、課金単位そのものを見直します。

最初に、価格、利用者一人あたりの変動費、月に対応できる利用者数を置きます。

一人あたりの粗い余力
= 税を除いた受取額
- 決済手数料
- 外部API・保存・配信などの変動費
- 問い合わせと保守に使う時間の見積額

この計算は利益を保証するものではありません。利用者が増えるほど赤字が広がる構造や、自分の対応時間を無視した価格を早く見つけるためのものです。少ない利用者数、想定数、上限に近い数の三通りで計算します。

公開前に、開発へ関わっていない人へ料金ページだけを見てもらい、次を尋ねます。

説明が一致しなければ、プランを増やさず文章と構造を直します。最初の価格案には見直す日を付け、その日までは致命的な問題を除いて条件を固定すると、反応を比較しやすくなります。