2021年、あるクライアントから電話がかかってきた。声には本当のパニックが込められていた。14ヶ月かけて請求書管理プラットフォームのカスタム開発に140,000ポンドを費やしたというのだ。開発チームはスペックのおよそ60%をリリースしただけだった。そして11ヶ月目あたりで、彼は気づいてしまった。Invoice Ninjaが存在し、オープンソースで、自分が必要な機能の90%を箱から出してすぐに提供していることに。しかも無料だ。
重要なポイント：サブスクリプション税、データ所有権、またはワークフロー不適合が本当に問題になるまでは SaaS を購入し、そのツールがビジネスの勝因となる場合にカスタム構築する。
あの電話は今でも少し心に引っかかっている。なぜなら、正直に答えると、私も反対の過ちを犯しているからだ。Seahawkは2019年にプロジェクトを抱えていたが、5つの異なるSaaSツール、Airtable、Zapier、Typeform、HubSpot、そしてカスタムWebflow CMSを8ヶ月かけてつなぎ合わせて、クライアントのワークフロー管理をしていた。後から考えると、15,000ポンドのカスタム開発でスッキリと恒久的に解決できていたはずだ。そのころ、サブスクリプションの合計月額は約900ポンドになっていた。3年間の数字を計算してみてほしい。
どちらの極端も自動的に正しいわけではない。そして「常に構築しろ」「決して構築するな」という明確なルールを売りつけてくる人間は、何かを売っているのだ。だから、創業者が私のところに来てこの質問をしてくるとき、私が実際に使うフレームワークがある。
---
まず、実際に何を決めているのかを認識する
これは技術的な決定ではない。正直に言えば、違う。技術の服を着た経営判断だ。
「構築すべきか、購入すべきか」と聞くとき、実は「差別化はどこに存在するのか」と聞いている。構築を検討しているものがあなたのプロダクトの核で、顧客があなたを競争相手のタブより選ぶ理由なら、構築は筋が通っている。それがインフラストラクチャー、管理機能、またはコモディティ機能なら、購入がほぼ確実に本当の意味で安い。
ファウンダーに最初に聞く質問は1つだ：ユーザーはこれを見ることになるか。答えがはい、そしてそれが有意義な方法で彼らの経験を形作るなら、構築する価値があるかもしれない。バックオフィス、運用、または社内向けなら、構築のハードルは非常に高くするべきだ。
---
自分たちで作る実コスト（驚くほど過小評価されている）
ぶっちゃけ言う。カスタム開発は思ったより高くつき、言われるより時間がかかり、誰も予算を組まない継続的な保守が必要だ。
ファウンダーが価格計算に入れ忘れるもの
- メンテナンスとホスティング。一度きりではない。その機能を廃止しない限り、ずっと責任を負い続けることになる。
- セキュリティパッチ。SaaS ベンダーがこれを処理してくれる。自分で構築したなら、午前2時のアラートを含めて、すべてを所有することになる。
- 新しい開発者のオンボーディング。主力エンジニアが去れば、次の人はあなたのコードベースを学ぶ必要がある。それは数週間分の請求対象時間だ。
- スコープクリープ。ステークホルダーはカスタムツールを見ると、それがすべてのことを実行できると想定する。スコープが拡大し、コストもそれに伴う。
私が使う大まかなルール：初期の開発見積もりを取り、現実的な納期のために1.6倍にして、その数字の年間保守費用として20%を加える。それらの数字でもビジネスケースが成り立つなら、素晴らしい。そうでなければ、答えが出ている。
正直に言うと、Standish GroupのCHAOS Reportは何十年も前から、ソフトウェア プロジェクトが予算をオーバーランする割合が驚くほど高いことを示している。プロジェクトの45～50%が「課題を抱えた」または完全に失敗している。これは「決して構築するな」という理由ではなく、目を大きく見開いて進めよということだ。
---
SaaSの本当のコスト（やはり過小評価されているが、理由は異なる）
SaaSは安く見えるが、そうでなくなる時点までだ。
年の初めに合理的に見えた月額49ポンドのプランには、3年経つ頃に月額490ポンドになるという癖がある。より高いティアに移り、シートを追加し、ベンダーが「価格体系を改定した」（つまり値上げした）ら、そうなる。SalesforceやIntercom、Mixpanelでこれがクライアントに起きるのを見てきた。それは悪意ではない。SaaSの経済学がそういう仕組みなだけだ。
ファウンダーが陥るSaaSの3つの罠
- ベンダーロックイン。あなたのデータは彼らのフォーマット、彼らのスキーマ、彼らのエクスポートフローの中にある。離脱は苦痛を伴い、時には重大なデータエンジニアリング作業なしに事実上不可能な場合もある。
- フランケンスタック複雑性。Zapierで何とか統合している5つのツールはシステムではない。それはリスクだ。1つのAPI廃止でことごとく崩れ始める。
- サブスクリプションの蔓延。誰もツールスタックを年1回監査していない。監査すべきだ。去年12人のエージェンシーを監査したら、使用を中止していたか、1つの機能だけで使用していたSaaSが月3,200ポンド分見つかった。
とはいえ、コモディティ機能については、SaaSはほぼ常に正しい選択肢だ。メール配信？PostmarkかSendGrid。決済？もちろんStripe。認証？Auth0かClerk。2024年に独自の決済プロセッサーを構築しようという人はいないはずだ。
---
実際に機能するフレームワーク
さて。ここが私の考え方だ。4つの質問を順番に。
質問1：これは競争上の差別化要因か？
もしそうなら、もしこれがあなたのプロダクトを本当に違うものにする要素なら、構築は真剣に検討する価値がある。そうでなければ、ここで止めよう。購入しろ。
質問2：十分なSaaS代替案は存在するか？
完璧ではなく、十分なもの。創業者たちは「我々に必要なことを正確にこなすものが何もない」という理由で構築することがよくある。時にそれは本当だ。多くの場合、それは彼らが十分に探していない、または「これをよく設定する必要がある」を「何か新しい構築が必要」と混同していることを意味している。
カスタム開発を勧める前に、SaaSマーケットの調査に最低でも2時間は費やす。Product HuntとG2はここで本当に役に立つ。福音書としてではなく、単なる出発点のインベントリーとしてだが。
質問3:現実的な価値実現までの期間はどのくらいか？
SaaSツールは今日にでもローンチできます。カスタムビルドは最短でも数週間、通常は数ヶ月かかります。スピードが重要な場合、そして初期段階の企業ではほぼ常にそうですが、購入することで、構築にコミットする前に実際に何が必要かを学ぶ時間を買うことができるのです。
2022年、Seahawkはカスタムルート最適化ダッシュボードを望むロジスティクススタートアップと仕事をしました。私たちは彼らをホワイトラベルAPIレイヤーを最初に使うよう説得しました（彼らはRoute4Meを出発点として使用しました）。6ヶ月後、彼らは顧客が実際に気にかけている機能がどれかを正確に知っていました。最終的に依頼されたカスタムビルドは規模が半分で、スペック書ではなく本番環境で学んでいたため、2倍優れていました。
質問4:これが破損したらどうなるのか？
なぜなら壊れるからです。問題は誰が修正するか、どのくらい早く修正するかです。SaaSなら、サポートチケットを送って、Twitterで文句を言います。カスタムソフトウェアなら、開発チームに電話します。開発チームを確保していなければ、問題です。これは仮説ではなく、フリーランス開発者が休暇に行ったために壊れたカスタムソフトウェアで数週間身動きが取れない創業者を見てきました。
---
構築が明らかに正解である場合
カスタム開発が明らかに正しい状況があります。明確に名前を挙げましょう。
- あなたのコアIPはソフトウェア自体だ。SaaS製品を売っているなら、売っている物を外注することはできない。
- 規制要件は既製品では不十分だ。特定のフィンテック、医療、法務向けアプリケーションはほとんどのSaaSツールが満たすよう構築されていないコンプライアンス制約を持っている。
- SaaSツールで既に検証済みで、正確に必要なものがわかっている。カスタムビルドを発注する前に、可能な限り最良のポジションだ。
- スケール時のSaaS価格は本当の所有よりも高い。Year 3の予測使用量で計算してみてください。時々カスタムが純粋な経済学で勝つ。
---
購入が明らかに正解な場合
同様に、購入が明白な状況もある。
- 売上がないか、プロダクト・マーケット・フィットに達していない。それだけだ。
- その機能は商品インフラ、メール、支払い、認証、ストレージ、分析です。
- 来年ではなく今四半期に機能させる必要がある。
- チームに社内エンジニアリング能力がなく、適切に人を雇う余裕がない。
それにもう一つ付け加えるなら。もしあなたがより難しいビジネス上の決定を避けるために創業者として構築しているなら、それは掘り下げる価値がある。カスタム構築は非常に高くついた形式の先延ばしになり得る。
---
ハイブリッドアプローチ（多くの場合、最善の選択肢）
誰もが十分に話さないことがある。構築と購入は相互排他的ではないということだ。
何度も成功しているのを見た最も実用的なアプローチは、商品の部分は積極的に購入し、差別化されたロジックの薄いレイヤーをその上に構築することです。あなたのCRMはHubSpot。サポートデスクはIntercom。ですが、それらを接続し、あなた特有のプロセスを自動化するカスタムワークフローエンジン？それは6ヶ月ではなく2週間のカスタム開発です。
Seahawkでは、購入したプラットフォームであるWordPress上に数百のサイトを構築し、本当に新しいものを実現するカスタムプラグインを作りました。プラットフォームが80%を処理します。私たちは重要な20%を構築します。つまらないアドバイスです。ですが最も頻繁に成功したアドバイスでもあります。
---
よくある質問
自分のユースケースがカスタム構築を正当化するほど本当にユニークかどうか、どうやって判断すればいいのか？
正直な答え：ほとんどはそうではありません。真剣に一午後、つまり20分ではなく4、5時間かけて、あなたのカテゴリーのあらゆるSaaS製品をマッピングすることから始めてください。それをやった後も何もあなたのコア要件をカバーしていないなら、その要件が本当に今必要なのか、それとも本来は良いに越したことはないものをブロッカーに昇格させたのかを自問してください。本当に必要で本当に誰も対応していないなら、それは深刻に受け止める価値のあるシグナルです。
カスタムソフトウェアを責任を持って保有するのに必要な最小限のチームサイズはどのくらいか？
最低限：コードベースを深く理解している1人の開発者、そして彼らが利用できないときにカバーできる2番目の開発者または確保されたエージェンシーのいずれか。1人のフリーランサーとバックアップなしでカスタムソフトウェアを所有することは危険な立場です。その1人が利用できなくなった場合、休暇、病気、より良い仕事の提案で、実際の運用上の被害をもたらすのを見てきました。
社内で構築すべきか、それとも代理店に構築させるべきか？
ほぼ完全に、ソフトウェアがあなたのコア事業かどうかで決まります。ソフトウェア企業であれば、最初は代理店を使うにしても、最終的にはほぼ確実に社内開発を望むことになります。ソフトウェアが事業そのものではなく、事業をサポートするツールであれば、適切なSLAを備えた代理店関係は、通常、エンジニアをフルタイムで雇うよりもコスト効率が高いです。
オープンソースは構築と購入の間の中間的な道か？
そうですし、過小利用されています。Metabaseなどの分析ツール、Directusのようなヘッドレスキャパシティ、またはERPNextなどのオペレーションツールは、初期構築コストが大幅に低いカスタムソフトウェアの柔軟性を提供します。落とし穴は：あなたはまだインフラを所有していて、それを管理するために技術者が必要です。無料ではなく、始めるのに安いだけです。
---
最後に
構築対購入の質問には一つの答えはない。あなたの答えがある。あなたのステージ、チーム、競争上の位置、そしてこれまでに実際に検証したものに特有の答えが。
私が反論したいのは構築に関するロマンティシズムです。カスタムソフトウェアは、よく構成されたSaaSスタックよりも本質的により真剣ではなく、より拡張性があり、またはより印象的ではありません。最初に言及した請求書作成の創業者？彼は最終的に本当にカスタムなものを構築しましたが、18ヶ月のInvoice Ninja使用が彼の顧客が本当に何を必要としているかを教えた後だけです。構築は待った甲斐がありました。
つまらない選択肢で始めましょう。新しいものを構築する権利を勝ち取ってください。
関連記事：Next.js & Supabaseでリアルタイムオークションサイトを構築する、カスタムウェブ開発、およびNext.js。