アプリ開発で見落としがちな費用：予算の実践ガイド

アプリ開発で見落としがちな費用とは、開発見積もりに含まれない支出のことで、企画、外部サービス、リリース作業、継続的な運用などの費用が該当します。これらを予算に組み込むには、単発の作業と、定期的な支払いや利用量に応じた料金を分けましょう。見積もりの対象外となる項目と所有権を書面で確認し、収益が入る時期が遅れた場合に運用費をどう賄うか計画しましょう。

アプリ開発で見落としがちな費用には何がある？

アプリ開発で見落としがちな費用とは、開発見積もりの対象外だったり、誰が負担するかが曖昧だったりするために、予算から漏れてしまう支出のことです。合意したソフトウェアの開発が見積もりに含まれていても、その運用に必要なものすべてが含まれているとは限りません。たとえば、AppDesign360のモバイルアプリ開発サービスでは、機能、プラットフォーム、サービス提供事業者の料金、スケジュールを書面の見積もりで確認するため、最低価格を運用費すべて込みの予算と考えないようにしましょう。

総保有コストとは、アプリの開発、運用、保守から、最終的な置き換えやサービス終了までにかかる費用の総額です。予約アプリなら、予約画面だけでなく、決済サービス、サポート、将来のデータ書き出しまで考えるということです。資金面の判断に合った計画期間を決め、その間に見込まれる費用を含めましょう。

事前に開示されていない料金と、通常の運用費は別の問題です。契約前に示されたホスティング費は隠れた費用ではありませんが、開発費だけを予算に入れていると、想定外の出費になりかねません。見積もりに含まれる項目だけでなく対象外の項目も提示してもらい、外部サービスごとに誰が支払うかを明記してもらいましょう。

非営利団体の予約アプリなら、リマインダー機能を作る費用と、その機能が送るメッセージの料金を分けましょう。機能の導入を承認しても、継続的にかかる料金を見落としてしまうことがあります。予算の各項目に支払いが発生する条件と責任者を設定し、金額が不明なものはゼロとして扱わず、要確認と記しておきましょう。

企画、デザイン、開発範囲の変更はアプリ開発費用に含まれる？

計画策定、デザイン、作業範囲の変更が含まれるのは、書面の契約で定めた範囲に限られます。コーディング前にユーザーや要件を明確にする作業であるディスカバリーは、開発に組み込まれている場合でも、独自の成果物を定める必要があります。AppDesign360のモバイル開発サービスによると、別途提供されるApp Blueprintは1,250ドルからで、クリックして操作できるプロトタイプ、技術仕様書、開発見積もりが含まれます。これは計画策定を購入するものであり、完成したアプリを購入するものではありません。

クリックして操作できるプロトタイプでは、提案された画面遷移を試すことができます。一方、技術仕様書には、ソフトウェアが何を行う必要があり、どのように構築されるかが記載されます。ユーザー調査、既存システムとの接続の確認、デザインの修正が計画策定に含まれると思い込まず、確認しましょう。プロジェクト管理にも、意思決定や承認を調整する担当者が必要です。業務の流れを説明し、コンテンツを提供し、成果物を確認する時間は、開発者の請求書に一切記載されなくても、チームで見込んでおきましょう。

• 計画策定の各成果物と、その承認者を明記しましょう。
• デザイン修正への対応方法と、デザイン工程の完了条件を明記しましょう。
• コンテンツ、アカウントへのアクセス、期限内のフィードバックについて、それぞれの責任者を決めましょう。
• 受け入れ基準、つまり作業が契約内容を満たしていると判断できる、実際に確認可能な条件を定めましょう。

仮に予約アプリを作る場合、顧客が空いている予約枠を選び、予約確認を受け取れることを受け入れ基準にできます。後から複数のスタッフのカレンダーを追加すると要件が変わるため、承認する前に、その費用とスケジュールへの影響を確認しましょう。このような依頼は、予約確認がすでに要件に含まれているのに機能しないといった不具合とは区別しましょう。記憶に頼って区別することにならないよう、変更と不具合に関する契約上の対応手順に、両方の例を盛り込みましょう。

1. 合意済みの作業範囲と照らし合わせて、依頼された変更を記録しましょう。
2. 変更による費用とスケジュールへの影響を書面で確認しましょう。
3. 実装を始める前に、その変更を承認するか、延期するか、取り下げるかを決めましょう。

独立した計画策定の工程が特に役立つのは、業務の流れや技術的な依存関係に未解決の点が残っている場合です。範囲が限定され、要件も明確な作業であれば、計画策定の範囲を小さくしても十分かどうかを確認しましょう。標準パッケージの規模ではなく、解消すべき不確実性に合わせて判断することが大切です。

プラットフォームや開発者の採用に関する選択は、アプリの予算にどう影響しますか？

プラットフォームや開発者の採用に関する選択によって、依頼する作業内容が変わるため、最低価格や時間単価ではなく、納品までに含まれる作業範囲全体を比較しましょう。AppDesign360のモバイル開発サービスによると、開発費用は合意した初期範囲で3,500米ドルからで、対象プラットフォームと機能は書面で確認します。提示されている選択肢には、SwiftとKotlinによるネイティブ開発や、FlutterとReact Nativeを使ったコード共有型の開発があります。いずれも、その名称だけでは完成品にいくらかかるかはわかりません。

iOSとAndroidの両方に対応するには、コードを共有していても、実装、テスト、リリース計画で両方のプラットフォームをカバーする必要があります。コードを共有すれば、その作業がなくなる、あるいは一定の費用削減が保証されるとは考えないでください。たとえば、オフィスのデスクで使う顧客向けポータルを想定した場合、モバイル版の開発・リリースを依頼する前に、ブラウザからのアクセスで要件を満たせるか確認しましょう。現場で働く人が端末の特定の機能を必要とする場合は、開発方針を選ぶ前に、その要件が妥当か検証してください。

人材の起用方法によって変わるのは、誰がコードを書くかだけでなく、誰が納品までの進行を管理するかも同じです。AppDesign360は、チーム内で働く人員を追加する「ITスタッフ増強」を1時間あたり20ドルからと案内していますが、この単価はプロジェクト全体の固定見積もりではありません。人材の起用方法を選ぶ前に、技術的な意思決定、テスト、引き継ぎに誰が責任を持つのかを比較しましょう。技術リーダーのいないチームでは、時間単価が安くても、管理責任を担う人は別途必要です。

どのような人材の起用方法でも、既存ツールとの接続や既存データの移動については、作業範囲を明確にする必要があります。システム連携はシステム同士をつなぐことで、データ移行は新しいアプリに情報を移すことです。予約サービスであれば、カレンダーとの接続と顧客データの取り込みについて、それぞれ別に確認しましょう。チームの所在地だけで価値が決まるわけでもありません。特に、遅れによって意思決定が滞る可能性がある場合は、会議に参加できる共通の時間帯と承認の責任分担について合意しておきましょう。AppDesign360は、コード、ホスティング、アカウントの所有権は顧客にあると明記しています。その所有権を実際に行使できるよう、支払い前にアクセス権と引き継ぎ作業を確認してください。

• 連携ごとに、誰がアクセス権を提供し、障害時のケースをテストするのか確認しましょう。
• 移行ごとに、移行元のデータ、必要なデータ整理、取り込み後の確認事項を定義しましょう。
• 引き継ぎでは、コードの保管場所、アカウント管理者、アプリの運用に必要な手順を明確にしましょう。
• 提案を比較する前に、各候補先に同じ成果要件で見積もりを依頼しましょう。

公開後も発生するホスティング、ソフトウェア、利用量に応じた料金には何がありますか？

運用予算には、公開後のインフラ、ソフトウェアのサブスクリプション、利用状況に応じた料金を見込む必要があります。バックエンドとは、予約を保存するデータベースや確認通知を送信するサービスなど、アプリの裏側を支えるサービスやデータシステムのことです。AppDesign360のサービス案内では、クラウドホスティング、ドメイン、その他のサービス提供元への支払いを、開発の人件費とは分けています。契約に明示的に含まれていない限り、これらの料金は別の予算項目として扱いましょう。

ホスティングはアプリケーションを動かすためのもので、データベースはユーザーが作成したり取得したりする情報を保持します。バックアップは復元可能なコピーを保存し、監視はチームがエラーやサービス停止を検知するのに役立ちます。AppDesign360は、SaaSインフラの対応範囲にこの両方を挙げています。ステージング環境とは、変更を顧客に届ける前にテストするための独立した環境で、専用のリソースを確保する必要があります。リリースと次のリリースの間も稼働し続けるリソースはどれか、バックアップにはどの情報を保持するのか、バックアップを復元できるかどうかの確認も含まれるのかを聞いておきましょう。

登録ユーザー数だけでは、アプリが有料サービスを呼び出す頻度はわかりません。予約アプリで、あるアカウントの利用者は予約を確認するだけで、別の利用者は何度も場所を検索し、リマインダーを受け取る場合を考えてみてください。ユーザー総数ではどちらも同じ1件のアカウントですが、発生する処理は異なります。メッセージの送信や決済処理も含め、一般的な予約が1件完了するまでの利用量を見積もり、そのうえでリクエストが失敗した場合やユーザーが操作を繰り返した場合に何が起こるかを確認しましょう。画面上の1回の操作が、必ずしも課金対象の処理1回に相当するとは限らないため、各プロバイダーが実際に定めている課金基準を使ってください。

• 有料サービスごとに、プロバイダー、課金単位、料金に含まれる利用枠、更新条件を記録しましょう。
• 毎月最低限支払う固定料金と、利用量に応じて増える料金を分けましょう。
• 請求を確認し、利用量のアラートを受け取る担当者を決めましょう。
• 支出を制限する機能が、サービスを停止するのか、警告を送るのか、それとも追加料金の発生を許容するのかを確認しましょう。
• サブスクリプションを解約した場合、保存データがどうなるかを文書に残しましょう。

役に立つ費用予測は、登録ユーザー1人あたりの費用を推測するのではなく、顧客の操作に沿って立てるものです。どの操作で外部サービスの料金が発生し、どこでリクエストの繰り返しが起こり得るかを開発担当者に洗い出してもらい、プロバイダーの現在のプランに照らして各操作の費用を算出しましょう。予約の業務フローにリマインダーが欠かせない場合、それを無効にする支出上限は、予算を制限するだけでなく、業務上の問題も引き起こします。こうしたアプリ開発で見落としがちな費用は、課金が発生する条件と、それを制限した場合の影響の両方を把握することで管理しやすくなります。

テスト、セキュリティ、アプリストアに関して、どのような費用を予算に入れるべきですか？

公開前の確認や公開作業は、コーディング費用に含まれていると思い込まず、明確に予算に組み込みましょう。品質保証はQAと略されることが多く、問題が起きた場合も含めて、アプリが意図どおりに動くかを確認することです。AppDesign360のアプリレビューサービスでは、製品に関係する場合、認証、権限、顧客データ、テストを評価項目としています。開発提案書には、確認項目、実施担当者、修正費用の負担者を明記してもらいましょう。

テスト計画では、対象とするデバイスとOSの範囲を定め、製品を使う人のためのアクセシビリティの確認も含める必要があります。アクセシビリティとは、障害のある人もアプリを使えることです。たとえば、画面読み上げ機能や拡大した文字で予約を完了できることを指します。認証は利用者が誰であるかを確認する仕組みで、権限はその人が何にアクセスし、何を変更できるかを定めるものです。顧客向けポータルでは、リンクを書き換えても、ある顧客が別の顧客の文書を取得できないことを示すテストを依頼しましょう。

• 受け入れ基準に、対応するデバイス、ブラウザー、OSのバージョンを明記しましょう。
• 決済の失敗、通信の中断、アカウントの復旧をテスト範囲に含めましょう。
• アクセシビリティの確認項目と、組織が必要とする専門家による評価を定めましょう。
• 個人情報の取り扱いに関する通知、同意の選択肢、データの保存方針の決定について、責任者を決めましょう。
• セキュリティテストや関連するコンプライアンス審査に、別途業務範囲を定めた専門家が必要かどうかを確認しましょう。

プライバシー保護とコンプライアンスに関する作業は、収集する情報、アプリの利用者、組織に適用される義務によって変わります。医療現場で患者情報を受け付ける製品では、通常のサインインテストで十分だと考えるのではなく、データの取り扱いと適用される要件を個別に評価する必要があります。その作業を見積もる前に、必要な証拠資料と審査の責任者を特定しましょう。AppDesign360は医療分野やHIPAAに関するAI導入支援を提供していますが、サービスが提供されているというだけでは、個々の製品が適用される義務を満たしていることの証明にはなりません。

AppDesign360のモバイル開発サービスにはApp StoreとGoogle Playへの申請が含まれているため、申請準備と、求められた変更への対応との境界を確認しましょう。リリース予算を承認する前に、対象国、製品の種類、プログラムの参加資格についてAppleとGoogleの最新の公式規約を確認し、そのうえで決済サービス事業者の適用料金を確認してください。すべての販売手数料と決済処理手数料が同じ購入に適用されるとは考えず、これらの区分を分けて管理しましょう。また、申請に追加作業が必要になった場合に、リリース日の変更を誰が担当するかも決めておきましょう。

継続的なWebアプリ開発には、どのような費用を見込むべきですか？

継続的なWebアプリ開発の費用には、リリース時に見つかった不具合の修正だけでなく、保守や顧客対応も含まれます。AppDesign360は、新規開発には30日間の修正対応が含まれ、その後も開発を担当したチームからサポートを受けられるとしています。その期間がいつ始まるのか、問題をどのように報告する必要があるのか、どのような修正が対象になるのかを確認しましょう。期間が定められた修正対応を、製品の変更を無制限に依頼できる枠と捉えるべきではありません。

合意した動作を基準に、不具合と新たな要件を区別しましょう。合意済みの作業範囲に含まれているのに予約確認が送信されない場合は、不具合修正の対象候補になりますが、2回目のリマインダーを追加する場合は新たな要件になります。問題を報告する際は、期待する動作と、正常に動かなかった結果を記録してください。こうすることで、依頼が小さなものに感じられるかどうかを議論するのではなく、双方が具体的な情報をもとに判断できます。

保守には、自社のコード以外の変更への対応も含まれます。たとえば、OSの更新や、アプリが利用するソフトウェア部品である依存コンポーネントの変更です。AppDesign360のSaaSサポートの案内では、料金に含まれる修正対応期間が終了した後も依頼できる作業として、監視、セキュリティ更新、バグ修正、新機能の追加が挙げられています。当初の開発費に一律の割合を掛けるのではなく、作業ごとの見積もりを依頼しましょう。たとえば、決済コンポーネントの変更後に互換性を確認する作業と、顧客向けのレポート画面を追加する作業は別のものです。

• 監視アラートを確認し、どの障害にすぐ対応すべきかを判断する担当者を決めましょう。
• 更新作業は、リリース前に必要なテストとあわせて見積もりましょう。
• 見込まれるサポート需要に応じて、利用開始の支援や顧客からの質問への対応に予算を確保しましょう。
• インシデント発生時の対応責任と、サポートを受けられる時間帯を明確にしましょう。
• プロダクトの改善と、既存の機能を動かし続けるために必要な作業を分けましょう。
• 顧客獲得を保守の一部として扱うのではなく、マーケティングには独自の作業計画と予算を用意しましょう。

ソフトウェアが正常に動いていても、顧客対応には担当者が必要です。非営利団体であれば、ボランティアがアカウントに再びアクセスできるよう職員が対応する時間が必要になる一方、全員に影響する障害にはテクニカルサポートが対応する場合があります。日常的な質問は組織内で対応し、技術的な支援は外部に委託することもできますが、顧客がアプリを頼りにするようになる前に、その体制を確認しておきましょう。実用的な予算では、繰り返し発生する作業ごとに、担当者、想定される作業量、追加支出の承認ルールをひも付けます。

AIやノーコードで開発したアプリには、どんな費用が隠れていますか？

AIやノーコードで開発したアプリでは、本番運用に向けた準備、プラットフォームの利用、将来の別システムへの移行に費用がかかることがあります。AIが書いたコードとは、ツールの助けを借りてソフトウェアを作成したことを指し、AI機能とは、アプリの利用中にAIサービスを呼び出す機能を指します。この2つでは、予算を考える際の検討事項が異なります。生成された予約フォームにはレビューとテストが必要ですが、AIアシスタントには、それに加えてモデルを継続的に利用するための予算も必要です。

AI機能の料金は、単にアカウントを持つ人の数ではなく、サービスの提供元と処理量によって決まります。課金単位には、モデルが処理するテキストの単位であるトークンなどが使われる場合があるので、別途かかるストレージやツールの料金とあわせて確認しましょう。助成金申請書の作成を支援するアシスタントなら、最初の指示への回答だけでなく、アップロードされた文書の読み取りや下書きの修正に必要な処理量を見積もりましょう。無制限の利用を約束する前に、利用上限を設定し、顧客が上限に達した場合の対応を決めておきましょう。

ノーコードツールでは画面上の操作でアプリを組み立てられますが、サブスクリプションの条件と利用を終了する際の条件は把握しておく必要があります。試作品で使っているプランで公開まで対応できると思い込まず、実際の業務の流れに必要なプランを確認しましょう。顧客データをエクスポートする機能と、動作するアプリケーションをエクスポートする機能は別のものです。たとえば、非営利団体がボランティア名簿をダウンロードできても、承認プロセスは別の環境で誰かに作り直してもらう必要があるかもしれません。

• 想定している利用者、外部連携、アクセス制御に対応するサブスクリプションのプランを確認しましょう。
• 料金が職員の利用アカウント数、データ件数、自動処理の実行回数、または別の課金単位で決まるのかを確認しましょう。
• 何をどの形式でエクスポートできるのか、別の開発者がプラットフォームの外でそのアプリケーションを動かせるのかを問い合わせましょう。
• 移行の見積もりには、データの整理、業務フローの再構築、テストを含めましょう。
• プラットフォームのアカウントを誰が管理しているのか、解約後も何にアクセスできるのかを確認しましょう。

AppDesign360のAI App Review & Launchサービスは、有料のプロダクトとコードのレビューから始まり、その後、調査結果と、現状維持・修正・再構築のいずれを勧めるかが書面で提示されますが、実装の範囲は別途定められます。つまり、このレビューは予算を判断するためのものであり、試作品がほぼ完成していると約束するものではありません。AppDesign360によると、別途提供されているコーチングサービスは1回125米ドルからで、完成までの作業を依頼する人ではなく、自分で開発を進める人を支援するものです。試作品で顧客からの支払いを受け付けている場合は、公開日を決める前に、レビュー結果と完成までに必要な作業範囲の提示を求めましょう。

収益が入るのが遅れる場合、公開に向けた予算はどう組めばよいですか？

顧客からの収入がなくても使える手元資金を基準にリリース予算を立て、開発費とサービスを利用可能な状態に保つための費用を分けましょう。AppDesign360は、開発範囲を定めたSaaSのMVPを1万5,000米ドルからと案内しており、最終的な開発範囲と見積もりは書面で確認します。SaaSはオンラインサービスとして提供されるソフトウェアを意味し、MVPは実用に必要な最小限の機能を備えた製品、つまり顧客の中心的な作業に焦点を絞った初回リリース版です。この開始価格は開発費の項目として扱い、必要な資金の総額とは考えないようにしましょう。

表計算シートには、銀行口座からいつお金が出ていくのかを示しましょう。総額だけでは、リリース前に起こる資金不足が見えないためです。開発費の支払いを合意済みの進捗段階に対応させ、見積もりに含まれない企画作業やリリース作業には別の行を設けましょう。各行に担当者、支払日、金額が変わる要因の説明があれば、アプリ開発で見落としがちな費用を見つけやすくなります。米ドル建ての請求書に支払うカナダの組織であれば、自組織の資金繰り予測で使う為替レートと支払手数料も明確にしましょう。

1. 書面で提示された開発費の見積もりと支払スケジュールを入力し、1万5,000米ドルという開始価格は、実際の開発範囲に対する見積もりが出るまでの仮の金額としてのみ使いましょう。
2. データ準備やリリース用コンテンツなど、見積もりに含まれない一度きりの作業を追加し、金額が決まっていない項目はゼロではなく未確定と記しましょう。
3. 毎月支払いが必要な固定費と従量料金を分けて記載し、各サービスの課金開始時期を記録しましょう。
4. 収入がない前提で計画する期間を決め、メッセージの送信や文書の処理など、顧客の操作をもとに利用量を見積もりましょう。
5. 運営に備える資金を計算し、未払いのリリース費用と金額を明示した予備費を加えて、その合計を使える手元資金と比較しましょう。
6. 見直し日と、次の支払期日が来る前に支出を判断する基準となる最低現金残高を設定しましょう。

計算例として、6か月分の運営資金を確保することにし、仮の月額予算として固定の運営費1,000米ドルと従量料金200米ドルを入力したとします。これらは表計算シートに入力するための仮の数値であり、AppDesign360の価格や市場相場の推定値ではありません。利用する事業者の見積もりと処理量の予測に置き換えてください。追加のリリース作業費はL、予備費はCとし、金額を割り当てるまではそのままにしておきましょう。以下のシナリオは、利用量が増える場合も含め、顧客からの入金がないことを前提としています。

遅延によって準備資金が減るのは、引き続き発生する費用の分だけです。そのため、すべての予算項目に機械的に期間を掛けるのではなく、各サービスの開始日を確認しましょう。無料トライアルや未払いの請求書があると、入金より先に利用が増えることがあるため、成長時についても別に検証する必要があります。使える資金が、未払いのリリース関連の支払予定額と設定した運営準備資金の合計を下回る場合は、追加作業を承認する前にリリース範囲を縮小するか、必須ではない支出を一時停止しましょう。一時停止する場合も、すべての請求がすぐに止まると考えるのではなく、顧客データの保全と既存の義務への対応について、費用を算出した計画が必要です。

支払い前にAppDesign360に確認しておくべきことは何ですか？

AppDesign360に支払う前に、何を購入するのか、見積もりに含まれないものは何か、引き渡し時に何を受け取れるのかを確認しましょう。契約で開発費と外部サービスの利用料、後からの変更、継続的なサポートを分け、それぞれの責任者を明記しておけば、アプリ開発で見落としがちな費用も計画に織り込みやすくなります。

AppDesign360は、2018年設立のMango Consulting LLCが展開する、ウェブサイト、SaaS、カスタムソフトウェア開発のブランドと説明しています。SaaSは「サービスとしてのソフトウェア」を意味し、顧客がオンラインで利用する製品です。同社は、米国中小企業庁（SBA）が認定する、軍務に起因する障害のある退役軍人が所有する中小企業（SDVOSB）で、小規模企業や成長中の企業、創業者、非営利団体にサービスを提供し、連邦政府の優先調達枠の業務も請け負っています。

AppDesign360の会社情報とサービス情報によると、現地チームはニュージャージー州ティーネックとニューヨーク州クイーンズを拠点に、米国とカナダ全域へリモートでサービスを提供しています。サービスはウェブサイト、ソフトウェア製品、マーケティングを対象としていますが、これらは個別に購入するもので、公開時のパッケージに当然含まれるものではありません。AppDesign360は、以下のサービス範囲と予算計画用の目安価格を米ドルで公開していますが、実際に含まれる作業は書面の契約で決まります。

たとえば、会員向けポータルの開発を依頼する非営利団体は、ログイン機能が使えればデータ移行も含まれると思い込まず、既存の会員データの取り込みが含まれるかを確認する必要があります。同じ合意書には、そのデータを誰が準備し、非営利団体がどのように成果を検収するかも記載する必要があります。このチェックリストを使って、大まかな約束を、支払いを承認する前に確認できる具体的な取り決めにしましょう。

• 成果物、対応プラットフォーム、対象外の作業を確認しましょう。別契約となる企画やレビューの業務も確認します。
• 合意した作業が完了したことを確認するための条件である「検収基準」を定め、コンテンツ、データ、承認の責任者を決めましょう。
• 価格、支払いのタイミングと条件、公開日を記録しましょう。承認や外部サービスが原因で納品が遅れた場合の対応も含めます。
• 変更を依頼する場合は、チームがその作業を始める前に、費用とスケジュールの承認を必須にしましょう。
• ホスティング、ストア、決済、その他のサービスのアカウントが誰の名義になっているか、各請求書を誰が受け取るかを確認しましょう。
• 受け取るコード、認証情報、ドキュメントを一覧にし、引き継ぎ時に自社のチームがアクセスできることを確認しましょう。
• 料金に含まれる修正の範囲、有料サポートが始まる時点、障害対応の作業を承認する担当者を定めましょう。

AppDesign360の20分間の無料初回相談では、公開までの予算と、対象外の項目について未解決の点をご相談ください：https://appdesign360.com/contact。実装を依頼すると決める前に、新製品の企画や既存の試作品のレビューなど、どの有料の次のステップが状況に合うかを確認しましょう。

アプリの費用はどのくらいですか？小さく始められますか？

最初のリリースで役立つ作業を1つ完結でき、すぐに売上がなくても運用資金を賄えるなら、小さく始められます。MVPとは、製品の核となる価値を検証するために、実際に使える最小限の機能を備えたリリースのことです。その予算にも、実際のユーザーにサービスを提供するために必要な作業の費用を含める必要があります。

たとえば、予約サービスなら、自動スケジュール調整は後回しにし、顧客からの予約リクエストとスタッフによる確定だけで公開する方法があります。これにより、初期のソフトウェアの開発範囲は小さくなりますが、スタッフの手作業は残るため、その費用を運用予算に含める必要があります。この方法を続けるのは、リクエストの見落としや許容できないサービス品質の低下を起こさずに、チームが対応できる間だけにしましょう。