Microsoft haalde deze week de COPILOT-formule weer uit Excel, en stopte met het gekoppelde licentiemodel voor VMware in Azure. Twee keer hetzelfde patroon: iets waar mensen op gingen bouwen, verdween weer. Dit gaat niet over storingen maar over functies die bewust worden geschrapt, en hoe je daar rekening mee houdt zonder alles zelf te bouwen.
Bij een storing wacht je. Bij een geschrapte functie moet je iets.
Een storing is vervelend en tijdelijk. Wat er gebeurt als een van je bouwstenen eruit ligt en hoe je daarop voorbereidt, staat in wat als je bouwplatform uitvalt. Deze pagina gaat over het andere geval: de functie komt niet meer terug, want de leverancier heeft besloten hem te schrappen.
Dat gebeurt vaker dan je zou denken en het is zelden persoonlijk. Een aanbieder brengt iets uit, ziet dat het te duur, te complex of te weinig gebruikt is, en haalt het weg. Soms is er een aankondigingstermijn, soms verdwijnt het gewoon uit de volgende versie. Microsoft haalde deze week de COPILOT-formule uit Excel weg, kort nadat mensen er werkbladen omheen hadden gebouwd.
Voor jou is de vraag dus niet of dit gebeurt, maar hoeveel het je kost als het gebeurt. En dat hangt bijna volledig af van hoe diep die functie in je product zit.
Aan de manier waarop iets wordt aangeboden, zie je meestal al hoe stevig het is.
De maatregel is niet alles zelf bouwen, maar zorgen dat vervangen een middag werk is.
Roep een externe functie nooit vanaf tien plekken aan, maar zet er één laagje omheen. Verdwijnt de functie, dan verander je dat laagje in plaats van je hele project. Dit kost je bij het bouwen tien minuten en het is de enige maatregel die echt scheelt.
Sla het resultaat van een externe aanroep op in je eigen database in plaats van hem elke keer opnieuw op te halen. Verdwijnt de dienst, dan heb je de gegevens nog en kun je rustig iets anders zoeken. Zonder die opslag ben je op de dag van afsluiting meteen alles kwijt.
Je hoeft geen tweede oplossing te bouwen, maar wel te weten wat je zou doen. Eén regel per afhankelijkheid: als dit wegvalt, dan dit. Dat kost je een halfuur en zet je in dezelfde notitie als je overzicht van wat er in je app zit.
Juist het nieuwste waar je op bouwt, is het minst stabiel.
De AI-laag verandert op dit moment sneller dan wat dan ook. Modellen worden vervangen, functies die in een preview zaten verdwijnen, en de manier waarop je iets aanroept wijzigt tussen versies. Dat is geen verwijt aan de aanbieders, het is het tempo van een markt die nog aan het uitkristalliseren is.
Praktisch betekent dat: leg de modelkeuze niet vast in je code maar in je configuratie, en schrijf je instructies zo dat ze niet volledig op de eigenaardigheden van één model leunen. Hoe je dat inricht staat in welk AI-model kies je voor je app.
Let ook op wat je aan de gebruiker belooft. Bouw je een functie die alleen bestaat dankzij iets in bèta, wees dan voorzichtig met het als kernfunctie in je verkoopverhaal te zetten. Verdwijnt de onderliggende dienst, dan verdwijnt niet alleen een stukje techniek maar ook een belofte die je hebt gedaan.
En kijk naar je licentievoorwaarden voordat je diep bouwt op iets van één partij. Dat een aanbieder zijn model kan wijzigen is normaal; dat je er niet meer uit kunt, is jouw ontwerpkeuze.
Bij een storing is de functie tijdelijk weg en komt hij terug, dus wacht je. Bij een geschrapte functie komt hij niet terug en moet je iets bouwen of vervangen. De voorbereiding verschilt daardoor: bij storingen gaat het om een terugvaloptie, hier om hoe diep de functie in je product zit.
Kijk naar drie signalen: staat er bèta, preview of experimenteel bij, is het gratis bij een bedrijf dat er geen geld aan verdient, en is de aanbieder recent overgenomen. Elk van die drie verhoogt de kans dat het verdwijnt, en ze komen vaak samen voor bij precies het soort nieuwe functie waar je enthousiast van wordt.
Nee, dat is bijna altijd duurder dan het risico. De verstandige maatregel is zorgen dat vervangen goedkoop is: roep een externe dienst vanaf één plek in je code aan in plaats van vanaf tien, en bewaar wat je eruit haalt in je eigen database. Dan is een geschrapte functie een middag werk in plaats van een herbouw.
Sommige leveranciers beloven dat ze een functie pas na een bepaalde periode weghalen, bijvoorbeeld twaalf maanden na aankondiging. Dat staat in hun beleid of in je contract. Voor iets waar je kern op leunt is dat een van de weinige harde toezeggingen die je kunt krijgen, en het is de moeite waard om ernaar te vragen voor je begint.
Omdat die markt nog beweegt. Modellen worden vervangen, previewfuncties verdwijnen en de manier waarop je iets aanroept verandert tussen versies. Leg de modelkeuze daarom in configuratie vast in plaats van in je code, zodat wisselen een instelling is en geen project.
Dan loop je een tweede risico naast het technische: je hebt een belofte gedaan die je niet zelf in de hand hebt. Wees daar terughoudend mee bij alles wat op iets in bèta leunt. Verdwijnt de dienst, dan moet je niet alleen bouwen maar ook uitleggen aan klanten die er juist voor kwamen.
Eén notitie met per externe afhankelijkheid: wat je ervan gebruikt, hoe stevig het staat en wat je zou doen als het wegvalt. Eén regel per stuk is genoeg. De waarde zit niet in het document maar in het feit dat je de vraag een keer hebt gesteld voordat het urgent werd.
Deels. Een open component kan ook worden gestaakt of van licentie veranderen, maar het verschil is dat de bestaande versie blijft werken en jij bepaalt wanneer je overstapt. Bij een gesloten dienst gaat de knop om op een moment dat een ander kiest. Dat maakt open componenten voor de kern van je product doorgaans het veiligere fundament.
Stuur ons je idee. Wij kijken in een intake mee welke flow je wilt testen en leveren in één werkdag een klikbaar prototype, met de juiste tools voor jouw geval.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.