2021年にクライアントから電話をもらった。声には本気のパニックが入ってた。140,000ポンドを14ヶ月かけて、カスタム請求書プラットフォームを作るために使い込んでた。開発チームが納品したのはスペックの60%くらい。そして11ヶ月目あたりで、Invoice Ninjaが存在すること、オープンソースであること、そして必要とするもののうち90%をそのまますぐに無料で実装できることに気付いたわけだ。Invoice Ninja existed, was open-source, and did 90% of what he needed out of the box. For free.
重要なポイント：サブスクリプション税、データ所有権、またはワークフロー不適合が本当に問題になるまでは SaaS を購入し、そのツールがビジネスの勝因となる場合にカスタム構築する。Buy SaaS until the subscription tax, data ownership, or workflow mismatch genuinely bites; build custom when the tool is core to how the business wins.
あの電話は今でも少し頭に残ってる。なぜなら正直に言うと、僕も逆の間違いをしてるからだ。Seahawkは2019年のプロジェクトで、8ヶ月間かけてAirtable、Zapier、Typeform、HubSpot、そしてカスタムWebflow CMSという5つの異なるSaaSツールを繋ぎ合わせて、クライアントのワークフロー管理をやってた。あとで思い返すと、15,000ポンドのカスタムビルドが完全にきれいに問題を解決してくれたはずだ。月末までに月額約900ポンドのサブスクリプション料金を払ってた。3年間でこれを計算してみてほしい。
どちらの極端も自動的に正しいわけじゃない。そして「常に作れ」「絶対に作るな」というきれいなルールを売ってる奴は、何かを売ってる。だから、起業家が僕に座って「どうするべき？」と聞いてきたときに使う実際のフレームワークがこれだ。
---
まず、実際に何を決めているのかを認識する
これは技術的な決定ではない。正直に言えば、違う。技術の服を着た経営判断だ。
「作るべき、それとも買うべき？」と言うとき、本当に聞いてるのはこういうことだ。その製品の中でも差別化はどこに住んでるのか？って。もしお前が作ることを考えてるものが、競争優位の中心にあるなら、つまり顧客がブラウザの次のタブを選ぶ代わりにお前を選ぶ理由が、それなら作るのは多分意味がある。インフラ、管理、商品化した機能なら、買うのはほぼ確実に実質的には安い。reason customers will choose you over the next tab in their browser -- then building probably makes sense. If it's infrastructure, admin, or commodity functionality, buying is almost certainly cheaper in real terms.
ファウンダーに最初に聞く質問は1つだ：ユーザーはこれを見ることになるか。答えがはい、そしてそれが有意義な方法で彼らの経験を形作るなら、構築する価値があるかもしれない。バックオフィス、運用、または社内向けなら、構築のハードルは非常に高くするべきだ。Will your users ever see this thing?If the answer is yes and it shapes their experience in a meaningful way, it might be worth building. If it's back-office, operational, or internal, the bar for building should be very high.
---
自分たちで作る実コスト（驚くほど過小評価されている）
ぶっちゃけ言う。カスタム開発は思ったより高くつき、言われるより時間がかかり、誰も予算を組まない継続的な保守が必要だ。
ファウンダーが価格計算に入れ忘れるもの
- メンテナンスとホスティング。一度きりではない。その機能を廃止しない限り、ずっと責任を負い続けることになる。Not a one-off. You're on the hook forever unless you sunset the thing.
- セキュリティパッチ。SaaS ベンダーがこれを処理してくれる。自分で構築したなら、午前2時のアラートを含めて、すべてを所有することになる。A SaaS vendor handles this for you. You build it, you own it, including the 2am alerts.
- 新しい開発者のオンボーディング。主力エンジニアが去れば、次の人はあなたのコードベースを学ぶ必要がある。それは数週間分の請求対象時間だ。If your lead engineer leaves, the next person needs to learn your codebase. That's weeks of billable time.
- スコープクリープ。ステークホルダーはカスタムツールを見ると、それがすべてのことを実行できると想定する。スコープが拡大し、コストもそれに伴う。Stakeholders see a custom tool and assume it can do everything. Scope expands. Costs follow.
私が使う大まかなルール：初期の開発見積もりを取り、現実的な納期のために1.6倍にして、その数字の年間保守費用として20%を加える。それらの数字でもビジネスケースが成り立つなら、素晴らしい。そうでなければ、答えが出ている。
率直に言って、Standish GroupのCHAOS Reportは数十年来、ソフトウェアプロジェクトが予算をオーバーランさせる率が深刻だってことを示してきた。プロジェクトの45～50%が「問題あり」か明確な失敗だ。これは絶対に作るなって理由じゃない。目を開いて臨めってことだ。Standish Group's CHAOS Report has been showing for decades that software projects overrun their budgets at an alarming rate. The number sits around 45-50% of projects being "challenged" or outright failing. That's not a reason to never build -- it's a reason to go in clear-eyed.
---
SaaSの本当のコスト（やはり過小評価されているが、理由は異なる）
SaaSは安く見えるが、そうでなくなる時点までだ。
年の始まりで妥当に見えた月額49ポンドのプランが、3年目までに月額490ポンドになってる奇妙な習性がある。もう高いティアにいて、シートを増やしたら、ベンダーが「価格構造の見直し」（読み：値上げ）をした後だからだ。Salesforce、Intercom、Mixpanelのクライアントでこれが起きるのを見た。悪意じゃない。SaaSの経済ってそういうもんだ。
ファウンダーが陥るSaaSの3つの罠
- ベンダーロックイン。あなたのデータは彼らのフォーマット、彼らのスキーマ、彼らのエクスポートフローの中にある。離脱は苦痛を伴い、時には重大なデータエンジニアリング作業なしに事実上不可能な場合もある。Your data is in their format, their schema, their export flow. Leaving is painful and sometimes effectively impossible without significant data engineering work.
- フランケンスタック複雑性。Zapierで何とか統合している5つのツールはシステムではない。それはリスクだ。1つのAPI廃止でことごとく崩れ始める。Five tools that sort-of integrate via Zapier is not a system. It's a liability. One API deprecation and things start falling apart.
- サブスクリプションの蔓延。誰もツールスタックを年1回監査していない。監査すべきだ。去年12人のエージェンシーを監査したら、使用を中止していたか、1つの機能だけで使用していたSaaSが月3,200ポンド分見つかった。Nobody audits their tool stack annually. They should. I ran an audit for a 12-person agency last year and found £3,200/month in SaaS they'd either stopped using or were using for one feature each.
そうは言ってもね。商品化した機能なら、SaaSはほぼ常に正しい選択だ。メール配信？PostmarkかSendGrid。決済？当然Stripe。認証？Auth0かClerk。2024年に自分で決済プロセッサを作ってる奴なんていない。Postmark or SendGrid. Payments? Stripe, obviously. Auth? Auth0 or Clerk. Nobody should be building their own payment processor in 2024.
---
実際に機能するフレームワーク
さて。ここが私の考え方だ。4つの質問を順番に。
質問1：これは競争上の差別化要因か？
もしイエスなら。もしこれがお前の製品を本当に違わせるものなら。作ることは本気で検討する価値がある。ノーなら、ここで止める。買え。
質問2：十分なSaaS代替案は存在するか？
完璧ではなく、十分なもの。創業者たちは「我々に必要なことを正確にこなすものが何もない」という理由で構築することがよくある。時にそれは本当だ。多くの場合、それは彼らが十分に探していない、または「これをよく設定する必要がある」を「何か新しい構築が必要」と混同していることを意味している。
カスタムビルドをお勧めする前に、SaaS市場を最低でも2時間かけてリサーチする。Product HuntとG2はここで本当に役に立つ。福音書としてじゃなくて、初期の棚卸しとしてな。Product Hunt and G2 are genuinely useful here -- not as gospel but as a starting inventory.
質問3:現実的な価値実現までの期間はどのくらいか？
SaaSツールは今日にでもライブできる。カスタムビルドは最低でも数週間、通常は数ヶ月かかる。スピードが重要なら――初期段階の企業ではほぼ常に重要だが――購入することで、構築にコミットする前に実際に必要なものを学ぶ時間を買える。
2022年にさかのぼるが、Seahawkはカスタムルート最適化ダッシュボードを望んでいたロジスティクススタートアップと仕事をした。私たちは彼らをホワイトラベルAPIレイヤーを最初に使うよう説得した（彼らはRoute4Meを出発点として使用した）。6ヶ月後、彼らは顧客が実際に気にかけている3つの機能が正確に何であるかを知っていた。彼らが最終的に発注したカスタムビルドは、仕様書ではなく本番環境で学んでいたため、スコープは半分――品質は2倍――だった。Route4Me as a starting point). Six months later, they knew exactly which three features their customers actually cared about. The custom build they eventually commissioned was half the scope -- and twice as good -- because they'd learned in production rather than in a spec document.
質問4:これが破損したらどうなるのか？
なぜなら壊れるから。問題は誰が直すのか、どのくらい速く直すのかだ。SaaSなら、サポートチケットを提出してTwitterで文句を言う。カスタムソフトウェアなら、開発チームに電話する。開発チームを確保していなければ、あなたは困っている。これは仮定の話ではない――フリーランス開発者が休暇に行ったために、創業者が壊れたカスタムソフトウェアで数週間身動きが取れなくなるのを見たことがある。
---
構築が明らかに正解である場合
カスタム開発が明らかに正しい状況があります。明確に名前を挙げましょう。
- あなたのコアIPはソフトウェア自体だ。SaaS製品を売っているなら、売っている物を外注することはできない。If you're selling a SaaS product, you can't outsource the thing you're selling.
- 規制要件は既製品では不十分だ。特定のフィンテック、医療、法務向けアプリケーションはほとんどのSaaSツールが満たすよう構築されていないコンプライアンス制約を持っている。Certain fintech, healthcare, and legal applications have compliance constraints that most SaaS tools aren't built to satisfy.
- SaaSツールで既に検証済みで、正確に必要なものがわかっている。カスタムビルドを発注する前に、可能な限り最良のポジションだ。This is the best possible position to be in before commissioning a custom build.
- スケール時のSaaS価格は本当の所有よりも高い。Year 3の予測使用量で計算してみてください。時々カスタムが純粋な経済学で勝つ。Do the maths at your projected Year 3 usage. Sometimes custom wins on pure economics.
---
購入が明らかに正解な場合
同様に、購入が明白な状況もある。
- 売上がないか、プロダクト・マーケット・フィットに達していない。それだけだ。
- その機能は商用インフラストラクチャだ――メール、決済、認証、ストレージ、分析。
- 来年ではなく今四半期に機能させる必要がある。
- チームに社内エンジニアリング能力がなく、適切に人を雇う余裕がない。
それにもう一つ付け加えるなら。もしあなたがより難しいビジネス上の決定を避けるために創業者として構築しているなら、それは掘り下げる価値がある。カスタム構築は非常に高くついた形式の先延ばしになり得る。to avoid making a harder business decision, that's worth examining. Custom builds can be a very expensive form of procrastination.
---
ハイブリッドアプローチ（多くの場合、最善の選択肢）
誰もが十分に話さないことがある。構築と購入は相互排他的ではないということだ。
何度も機能しているのを見た最も実用的なアプローチはこれだ――商用ピースを積極的に買収し、その上に差別化されたロジックの薄いレイヤーを構築する。あなたのCRMはHubSpot。サポートデスクはIntercom。しかし、それらを接続して特定のプロセスを自動化するカスタムワークフローエンジン？それは6ヶ月ではなく2週間のカスタム開発だ。
Seahawkでは、WordPress――購入したプラットフォーム――上で何百ものサイトを構築してきた。本当に新しいことをするカスタムプラグイン付きで。プラットフォームが80%を処理する。私たちが構築するのは重要な20%だ。退屈なアドバイスだ。また、最も頻繁に機能したアドバイスでもある。WordPress -- a bought platform -- with custom plugins that do genuinely novel things. The platform handles the 80%. We build the 20% that matters. It's boring advice. It's also the advice that's worked most often.
---
よくある質問
自分のユースケースがカスタム構築を正当化するほど本当にユニークかどうか、どうやって判断すればいいのか？
正直に答えると、ほとんどはそうではない。まず、真剣に午後を過ごそう――20分ではなく4時間か5時間、本気で――あなたのカテゴリーのすべてのSaaS製品をマッピングする。それをやってみて何もあなたのコア要件をカバーしていなければ、その要件が実は今必要なのか、それともブロッカーに昇格させた素敵な機能なのかを自問自答する。それが本当に必要で、本当にサービスされていなければ、それは真剣に受け取る価値のあるシグナルだ。necessary right now or whether it's a nice-to-have you've elevated into a blocker. If it's truly necessary and truly unserved, that's a signal worth taking seriously.
カスタムソフトウェアを責任を持って保有するのに必要な最小限のチームサイズはどのくらいか？
最小限：コードベースを深く理解している1人の開発者、および彼らが利用できない場合にカバーできる2番目の開発者か確保されたエージェンシーのいずれか。単一のフリーランサーとバックアップなしでカスタムソフトウェアを所有することは、脆い立場だ。その1人が利用できなくなった場合――休暇、病気、より良い求人オファー――実際の運用上の損害を引き起こすのを見たことがある。
社内で構築すべきか、それとも代理店に構築させるべきか？
ほぼ完全に、ソフトウェアがあなたのコア事業かどうかで決まります。ソフトウェア企業であれば、最初は代理店を使うにしても、最終的にはほぼ確実に社内開発を望むことになります。ソフトウェアが事業そのものではなく、事業をサポートするツールであれば、適切なSLAを備えた代理店関係は、通常、エンジニアをフルタイムで雇うよりもコスト効率が高いです。
オープンソースは構築と購入の間の中間的な道か？
はい、それは過度に使用されていない。Metabaseのような分析ツール、DirectusのようなヘッドレスCMS、ERPNextのような業務ツールは、カスタムソフトウェアの柔軟性を大幅に低い初期構築コストで与えてくれる。トレードオフ：あなたはまだインフラストラクチャを所有しており、それを管理するために技術的な誰かを必要としている。無料ではない――ただし開始時のコストが安いだけだ。Metabase for analytics, Directus for headless CMS, or ERPNext for operations give you the flexibility of custom software with significantly lower initial build cost. The catch: you're still owning infrastructure and you still need someone technical to manage it. It's not free -- it's just cheaper to start.
---
最後に
構築対購入の質問には一つの答えはない。あなたの答えがある。あなたのステージ、チーム、競争上の位置、そしてこれまでに実際に検証したものに特有の答えが。your answer, specific to your stage, your team, your competitive position, and what you've actually validated so far.
私が異を唱えたいのは、構築に関するロマンチシズムだ。カスタムソフトウェアは、本質的には、よく構成されたSaaS スタックより真剣で、スケーラブルで、印象的ではない。最初に述べた請求書発行創業者？彼は最終的に本当にカスタムなものを構築した――しかし18ヶ月後、Invoice Ninjaの使用が顧客が実際に必要としていることを正確に教えてくれた後だけだ。構築は待機のために良くなった。
つまらない選択肢で始めましょう。新しいものを構築する権利を勝ち取ってください。