Bouwen versus kopen is dood – AI heeft het zojuist gedood

Stel je dit voor: je zit in een vergaderruimte, halverwege een verkooppraatje. De demo ziet er solide uit en de prijzen passen mooi binnen het budget. De tijdlijn lijkt ook redelijk. Iedereen knikt mee.

Je bent letterlijk minuten verwijderd van het zeggen van ja.

Dan komt iemand van uw financiële team binnen. Ze zien de band en fronsen. Een paar minuten later sturen ze je een bericht op Slack: “Eigenlijk heb ik vorige week een versie hiervan samengesteld. Het kostte me 2 uur in Cursor. Wil je het zien?”

Wacht… wat?

Dit persoon codeert niet. Je weet zeker dat ze in hun hele leven nog nooit een regel JavaScript hebben geschreven. Maar hier zijn ze dan, ze tonen je een werkend prototype van hun laptop die doet… vrijwel precies wat de verkoper heeft gepitcht. Natuurlijk heeft het wat ruwe kantjes, maar het werkt. En het kostte geen zes cijfers. Slechts twee uur van hun tijd.

Plotseling kwamen de aannames waarmee je begon – over hoe software wordt ontwikkeldwie het maakt en hoe er beslissingen over worden genomen – alles begint uit zijn voegen te vallen.

Het oude raamwerk

Decennia lang heeft elk groeiend bedrijf dezelfde vraag gesteld: Moeten we dit zelf bouwen of moeten we het kopen?

En tientallen jaren lang was het antwoord vrij eenvoudig: Bouw als het de kern van uw bedrijf is; kopen als dat niet het geval is.

De logica was logisch omdat het duur was om te bouwen en tijd moest lenen van overwerkte ingenieurs, specificaties moest schrijven, sprints moest plannen, de infrastructuur moest beheren en zich moest voorbereiden op een lange reeks onderhoudswerkzaamheden. De aankoop verliep sneller. veiliger. U heeft betaald voor de steun en gemoedsrust.

Maar er is iets fundamenteels veranderd: AI heeft bouwen voor iedereen toegankelijk gemaakt. Wat vroeger weken duurde, duurt nu uren, en wat vroeger vloeiendheid in een programmeertaal vereiste, vereist nu vloeiendheid in gewoon Engels.

Nu de kosten en complexiteit van het bouwen zo dramatisch instorten, verdwijnen de oude raamwerken mee. Het is niet meer bouwen versus kopen. Het is iets vreemds waar we nog niet helemaal de juiste woorden voor hebben gevonden.

Als de markt (nog) niet weet wat jij nodig hebt

Mijn bedrijf was nooit van plan zoveel van de tools die we gebruiken te bouwen. We moesten gewoon bouwen omdat de dingen die we nodig hadden niet bestonden. En door dat proces ontwikkelden we een diepgeworteld begrip van wat we eigenlijk wilden, wat nuttig was en wat het wel of niet kon doen. Niet wat de leveranciers ons vertelden dat we nodig hadden of wat analistenrapporten zeiden dat we zouden moeten willen, maar wat feitelijk de doorslag gaf in ons bedrijf.

We ontdekten welke problemen de moeite waard waren om op te lossen, en welke niet. waar AI een echte hefboomwerking creëerde en waar het alleen maar lawaai was. En pas toen, toen we die zuurverdiende duidelijkheid hadden, begonnen we met kopen.

Op dat moment wisten we precies wat we zochten en konden we binnen ongeveer vijf minuten het verschil zien tussen inhoud en marketing. We stelden vragen die verkopers nerveus maakten, omdat we al een rudimentaire versie hadden gebouwd van wat ze verkochten.

Wanneer iedereen in enkele minuten kan bouwen

Vorige week merkte iemand van ons CX-team feedback van klanten op over een bug in Slack. Slechts een kleine klacht van een klant, niets belangrijks. Bij een ander bedrijf zou dit een supportticket hebben geactiveerd en zouden ze hebben gewacht tot iemand anders het zou afhandelen, maar dat is hier niet gebeurd. Ze openden Cursor, beschreven de wijziging en lieten de AI de correctie schrijven. Vervolgens dienden ze een pull-verzoek in dat de engineering beoordeelde en samenvoegde.

Slechts 15 minuten nadat de klacht in Slack verscheen, was de oplossing live in productie.

De persoon die dit heeft gedaan, is niet in het minst technisch. Ik betwijfel of ze je het verschil tussen Python en JavaScript konden vertellen, maar ze hebben het probleem toch opgelost.

En dat is het punt.

AI is zo goed geworden in het maken van relatief eenvoudige code dat het 80% van de problemen oplost waarvoor vroeger een sprintplanningsvergadering en twee weken engineeringtijd nodig waren. Het vervaagt de grens tussen technisch en niet-technisch. Werk dat vroeger door de techniek werd belemmerd, wordt nu gedaan door de mensen die het dichtst bij het probleem staan.

Het gebeurt nu in bedrijven die er daadwerkelijk op letten.

De inversie die plaatsvindt

Dit is waar het voor CFO’s fascinerend wordt, omdat AI feitelijk de hele strategische logica van bouwen versus kopen op zijn kop heeft gezet.

Het oude model ging ongeveer zo:

1. Definieer de behoefte.

2. Bepaal of je wilt bouwen of kopen.

Maar het definiëren van de behoefte duurde een eeuwigheid en vereiste diepgaande technische expertise, anders zou je geld verbranden via proefondervindelijke implementaties van leveranciers. Je zou talloze demo’s doornemen en proberen je voor te stellen of dit je probleem daadwerkelijk zou oplossen. Vervolgens zou je onderhandelen, implementeren, al je gegevens en workflows naar de nieuwe tool verplaatsen en zes maanden en zes cijfers later uitzoeken of (of niet) je had eigenlijk gelijk.

Nu is de hele reeks omgekeerd:

1. Bouw iets eenvoudigs met AI.

2. Gebruik het om te begrijpen wat u werkelijk nodig heeft.

3. Beslis vervolgens of je wilt kopen (en je weet precies waarom).

Met deze aanpak kunt u gecontroleerde experimenten uitvoeren. Je ontdekt of het probleem er überhaupt toe doet. Je ontdekt welke features waarde bieden en welke er in demo’s gewoon goed uitzien. Dus jij gaat winkelen. In plaats van u door een externe leverancier te laten vertellen wat de behoefte is, ontdekt u eerst of u die behoefte überhaupt wel heeft.

Bedenk eens hoeveel softwareaankopen u heeft gedaan waarmee u achteraf gezien problemen heeft opgelost die u eigenlijk niet had. Hoe vaak ben je drie maanden bezig geweest met een implementatie en dacht je: “Wacht even, helpt dit ons echt of proberen we alleen maar te rechtvaardigen wat we hebben gebruikt?”

Wanneer u nu iets koopt, wordt de vraag: “Lost dit het probleem beter op dan wat we al hebben bewezen te kunnen bouwen?”

Eén reframe verandert het hele gesprek. Nu verschijnt u op de hoogte van het telefoontje van de leverancier. Je stelt scherpere vragen en onderhandelt vanuit kracht. Het allerbelangrijkste is dat u de duurste fout in bedrijfssoftware vermijdt en een probleem oplost dat u nooit echt heeft gehad.

De val die je moet vermijden

Nu deze nieuwe mogelijkheid zich aandient, zie ik dat bedrijven de verkeerde kant op springen. Ze weten dat ze AI-inboorlingen moeten zijn, dus gaan ze winkelen. Ze zijn op zoek naar door AI aangedreven tools en vullen hun stapels met producten met GPT-integraties, chatbot-gebruikersinterfaces of ‘AI’ aan de marketingkant. Ze denken dat ze aan het transformeren zijn, maar dat is niet zo.

Bedenk wat de natuurkundige Richard Feynman noemde vrachtcultuswetenschap? Na de Tweede Wereldoorlog bouwden eilandbewoners in de Stille Zuidzee valse landingsbanen en controletorens, waarbij ze nabootsten wat ze tijdens de oorlog hadden gezien, in de hoop dat vliegtuigen vol vracht zouden terugkeren. Ze hadden alle attributen van een luchthaven: torens, koptelefoons, zelfs mensen die luchtverkeersleiders nabootsten. Maar er landden geen vliegtuigen, omdat de vorm niet de functie was.

Dit is precies wat er overal gebeurt met AI-transformatie in directiekamers. Managers kopen AI-tools zonder zich af te vragen of ze de manier waarop het werk wordt gedaan op betekenisvolle wijze veranderen, wie ze machtigen of welke processen ze ontsluiten.

Ze hebben de landingsbaan aangelegd, maar de vliegtuigen verschijnen niet.

En de hele markt is er feitelijk op gericht om jou in deze val te laten trappen. Alles wordt nu als AI bestempeld, maar het lijkt niemand iets uit te maken wat deze producten eigenlijk doen. Elk SaaS-product is voorzien van een chatbot of een functie voor automatisch aanvullen en heeft er een AI-label op geplakt, en het label heeft alle betekenis verloren. Het is slechts een selectievakje dat leveranciers moeten aanvinken, ongeacht of het echte waarde voor klanten creëert.

De fde nieuwe superkracht van het Inance-team

Dat is het deel dat mij enthousiast maakt over wat financiële teams nu kunnen doen. Je hoeft niet meer te raden. Je hoeft geen zes cijfers in te zetten op een verkoopstapel. Je kunt dingen testen en je kunt daadwerkelijk iets leren voordat je het gebruikt.

Dit is wat ik bedoel: als je software voor leveranciersbeheer evalueert, moet je een prototype maken van de kernworkflow met AI-tools. Ontdek of u een gereedschapsprobleem of een procesprobleem oplost. Ontdek of u überhaupt software nodig heeft.

Dit betekent niet dat je alles in eigen huis bouwt, natuurlijk niet. Meestal koop je toch iets, en dat is prima, want bedrijfshulpmiddelen bestaan ​​om goede redenen (schaling, ondersteuning, beveiliging en onderhoud). Maar nu koop je met je ogen open.

Je wilt weten hoe ‘goed’ eruit ziet. U krijgt demo’s te zien die de edge-case al begrijpen en binnen ongeveer 5 minuten weten of ze uw specifieke probleem daadwerkelijk begrijpen. Je implementeert sneller. Je onderhandelt beter omdat je niet volledig afhankelijk bent van de oplossing van de leverancier. En je zult ervoor kiezen omdat het echt beter is dan wat je zelf zou kunnen bouwen.

Je hebt de vorm van wat je nodig hebt al in kaart gebracht en je bent alleen nog op zoek naar de beste versie ervan.

Het nieuwe paradigma

Jarenlang was het mantra: bouwen of kopen.

Nu is het eleganter en veel slimmer: Bouw om te leren wat je moet kopen.

En het is geen toekomstige staat. Dit gebeurt al. Op dit moment gebruikt een klantvertegenwoordiger ergens AI om een ​​productprobleem op te lossen dat hij minuten geleden heeft ontdekt. Elders is een financieel team bezig met het prototypen van hun eigen analysetools, omdat ze zich hebben gerealiseerd dat ze sneller kunnen itereren dan dat ze technische vereisten kunnen schrijven. Ergens realiseert een team zich dat de grens tussen technisch en niet-technisch altijd eerder cultureel dan fundamenteel was.

De bedrijven die deze verschuiving omarmen, zullen sneller handelen en slimmer uitgeven. Ze zullen hun activiteiten beter kennen dan welke leverancier dan ook ooit zou kunnen. Ze zullen minder kostbare fouten maken en beter gereedschap kopen, omdat ze daadwerkelijk begrijpen wat gereedschap goed maakt.

De bedrijven die vasthouden aan het oude draaiboek zullen verkooppraatjes blijven uitzitten en meeknikken naar budgetvriendelijke voorstellen. Ze zullen debatteren over tijdlijnen en professionele decks blijven verwarren met daadwerkelijke oplossingen.

Totdat iemand uit zijn eigen team zijn laptop openklapt en zegt: “Ik heb gisteravond een versie hiervan gebouwd. Wil je het eens proberen?” en laat ze iets zien dat ze in twee uur hebben gebouwd en dat 80% doet van waar ze zes cijfers voor gaan betalen.

En zomaar veranderen de regels voor altijd.

Siqi Chen is de mede-oprichter en CEO van Runway.

Lees meer van onze gastschrijvers. Of overweeg om uw eigen bericht in te dienen! Zie de onze richtlijnen hier.