Bouwen versus kopen is dood – AI heeft het zojuist gedood

Stel je dit eens voor: je zit in een vergaderruimte, halverwege een verkooppraatje. De demo ziet er solide uit en de prijs past 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 je financiële team binnen. Ze zien het dek 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 een kijkje nemen?”

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 laten je een werkend prototype zien op hun laptop dat doet… vrijwel precies wat de verkoper heeft gepitcht. Natuurlijk, het heeft wat ruwe kantjes, maar het werkt. En het kostte geen zes cijfers. Slechts twee uur van hun tijd.

Plotseling kwamen de aannames waarmee je binnenkwam – over hoe software wordt ontwikkeldwie het maakt en hoe beslissingen eromheen worden genomen – het begint allemaal uit elkaar te vallen.

Het oude raamwerk

Decennia lang stelde elk groeiend bedrijf dezelfde vraag: 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 klopte, want bouwen was duur en betekende het lenen van tijd van overwerkte ingenieurs, het schrijven van specificaties, het plannen van sprints, het beheren van de infrastructuur en het voorbereiden van een lange reeks onderhoud. Kopen ging sneller. Veiliger. Je hebt betaald voor de steun en de 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.

Wanneer de kosten en complexiteit van het bouwen zo dramatisch instorten, gaat het oude raamwerk met hen ten onder. 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 leveranciersdecks 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 binnen 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 hierdoor een supportticket zijn gestart en hadden ze gewacht tot iemand anders het zou afhandelen, maar dat is hier niet gebeurd. Ze openden Cursor, beschreven de wijziging en lieten AI de oplossing schrijven. Vervolgens dienden ze een pull-verzoek in dat de engineering beoordeelde en samenvoegde.

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

De persoon die dit heeft gedaan, is in het geheel niet 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 ontwikkelen 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.

Dit gebeurt nu in bedrijven die daadwerkelijk opletten.

De inversie die plaatsvindt

Hier wordt het fascinerend voor financiële leiders, omdat AI feitelijk de hele strategische logica van de beslissing over bouwen versus kopen op zijn kop heeft gezet.

Het oude model ging ongeveer als volgt:

1. Definieer de behoefte.

2. Bepaal of u wilt bouwen of kopen.

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

Nu wordt de hele reeks omgedraaid:

1. Bouw iets lichts met AI.

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

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

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

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

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

Die ene herformulering verandert het hele gesprek. Nu verschijnt u op de hoogte van leveranciersoproepen. Je stelt scherpere vragen en onderhandelt vanuit kracht. Het allerbelangrijkste is dat u de duurste fout in bedrijfssoftware vermijdt, namelijk het oplossen van een probleem dat u nooit echt heeft gehad.

De valkuil die je moet vermijden

Nu deze nieuwe mogelijkheid zich aandient, zie ik hoe bedrijven de verkeerde kant op sprinten. Ze weten dat ze AI-native moeten zijn, dus gaan ze shoppen. Ze zoeken naar door AI aangedreven tools en vullen hun stapel met producten met GPT-integraties, chatbot-UI’s of ‘AI’ die op de marketingsite zijn geslagen. Ze denken dat ze aan het transformeren zijn, maar dat is niet zo.

Weet je nog wat 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 uiterlijke vormen van een luchthaven: torens, koptelefoons, zelfs mensen die vluchtleiders nabootsten. Maar er landden geen vliegtuigen, omdat de vorm niet de functie was.

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

Ze hebben de landingsbaan aangelegd, maar de vliegtuigen komen niet opdagen.

En de hele markt is er feitelijk op gericht om jou in deze val te laten trappen. Alles wordt nu als AI gebrandmerkt, 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 daadwerkelijke waarde voor klanten creëert.

De fde nieuwe superkracht van het Inance-team

Dit is het onderdeel 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 geld uitgeeft.

Dit is wat ik bedoel: als je software voor leveranciersbeheer evalueert, maak dan een prototype van de kernworkflow met AI-tools. Ga na of u een gereedschapsprobleem of een procesprobleem oplost. Zoek uit of je überhaupt software nodig hebt.

Dit betekent niet dat je alles intern gaat bouwen – natuurlijk niet. Meestal zul je toch kopen, en dat is prima, want bedrijfshulpmiddelen bestaan ​​om goede redenen (schaal, ondersteuning, beveiliging en onderhoud). Maar nu koop je met je ogen wijd open.

Je weet hoe ‘goed’ eruit ziet. U krijgt demo’s te zien die de randgevallen al begrijpen, en u weet binnen ongeveer vijf minuten 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 kiest ervoor 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 gaat 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 u moet kopen.

En het is niet een toekomstige toestand. Dit gebeurt al. Op dit moment gebruikt een klantvertegenwoordiger ergens AI om een ​​productprobleem op te lossen dat hij minuten geleden heeft opgemerkt. Ergens anders is een financieel team bezig met het prototypen van hun eigen analytische hulpmiddelen, omdat ze zich hebben gerealiseerd dat ze sneller kunnen itereren dan dat ze vereisten voor engineering kunnen opschrijven. 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 dure fouten maken en beter gereedschap kopen omdat ze daadwerkelijk begrijpen wat gereedschap goed maakt.

De bedrijven die vasthouden aan het oude draaiboek zullen de pitches van verkopers blijven volgen en meeknikken bij budgetvriendelijke voorstellen. Ze debatteren over tijdlijnen en blijven professionele decks verwarren met daadwerkelijke oplossingen.

Totdat iemand van zijn eigen team zijn laptop openklapt en zegt: “Ik heb gisteravond een versie hiervan gebouwd. Wil je het eens proberen?”, En hen iets laat 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 voorgoed.

Siqi Chen is mede-oprichter en CEO van Runway.

Lees meer van onze gastschrijvers. Of overweeg om zelf een bericht te plaatsen! Zie onze richtlijnen hier.