Bouw versus. Kopen is meestal echt nu vs. Later

Heruitgegeven door Plato

volgers: 0

In de beginperiode, misschien zelfs wel $10 miljoen-$20 miljoen aan ARR, zul je, als je met grotere prospects praat, veel 'Build vs Buy'-discussies hebben. We hebben deze niet zo vaak gehoord in de gekke tijden van eind 2020 – begin 2022, toen de budgetten om SaaS te kopen explodeerden. Maar de pushback is weer van kracht:

"Oh, ons IT-team zou het kunnen bouwen." Of
“We zullen proberen de functionaliteit te hacken met een product dat we al hebben.”
“We gaan eerst kijken of we het zelf kunnen doen.”

Je zult ergens tussen een beetje en veel hiervan horen totdat (x) je een zeer gerenommeerd merk hebt en (y) een product met extreem veel functies.

Ongetwijfeld is het in de beginperiode vaak een beetje waar. Als jouw drie engineers zes maanden zouden besteden aan het bouwen van een hack, zouden natuurlijk nog eens drie geweldige engineers hetzelfde kunnen doen. Sterker nog, ze kunnen het sneller en beter dan jij. Omdat u al een stappenplan heeft gemaakt om aan de slag te gaan met uw app.

Maar uiteindelijk is het een verkeerde keuze:

Zelfs als uw potentiële klant het zelf bouwt, kunnen ze het niet onderhouden De ingenieur die het heeft gebouwd, of het samen heeft gehackt op Slack of wat dan ook, zal vertrekken. Of ga door naar een ander project. Of zoiets. Wie onderhoudt deze aangepaste oplossing in jaar 2 en jaar 3? Bijna altijd - niemand.
Zelfs als ze het kunnen behouden, kunnen ze het niet ontwikkelen. Niet zoals jij kunt. Uw vijf ingenieurs zullen uitgroeien tot tien en vervolgens tot vijftig, en zij zullen niets anders doen dan uw product beter maken. Een interne oplossing kan die rijkdom aan functies en ervaringen nooit repliceren. Die raken binnen een paar jaar oud, tenminste, bijna altijd.
Ze zijn meestal niet aan de haak genoeg. Zelfs als uw klant het kan bouwen, wie wordt er dan om twee uur 's nachts wakker om de problemen op te lossen? Wie doet er nog een schepje bovenop om ervoor te zorgen dat de app doet wat de klant echt nodig heeft? Alleen jij. Het interne team van uw klant gaat om 2 uur en in het weekend naar huis.
De behoeften van uw klant evolueren bijna altijd sneller dan hun interne team Zelfs als ze het nu kunnen bouwen… kunnen ze volgend jaar waarschijnlijk niet. Of het jaar erna.

Dus netto netto – beschouw een verloren ‘build vs buy’-beslissing slechts als een kans met een langere verkoopcyclus. Over een jaar of twee krijg je ze. Of nog waarschijnlijker: binnen drie tot zes maanden, wanneer het interne project tot stilstand komt.

Zoals gewoonlijk.

Wees dus cool als u een deal verliest door een intern project. Het allerbelangrijkste is dat u regelmatig follow-up geeft — en waarde toevoegt als u dat doet Kijk of alles volgens plan verloopt. En vooral - verbreek de relatie niet als je de deal in eerste instantie verliest. Vertel hen dat u het begrijpt, en of en wanneer ze een externe leverancier nodig hebben - u bent er voor hen. Voor altijd.

(opmerking: een bijgewerkte SaaStr Classic-post)

Gepubliceerd op april 20, 2023