Doorontwikkelen

Een platform wordt niet gelanceerd. Het begint.

De eerste release is het moment waarop echte gebruikers, echte data en echte processen samenkomen. Vanaf dan weet je meer over je platform dan tijdens alle maanden ervoor, en vanaf dan begint ook het langste deel van zijn leven.

Twee soorten werk na live

Na de eerste release lopen er twee dingen naast elkaar. Die houden we bewust apart.

Een SLA die het technisch gezond houdt. Securitypatches, updates van frameworks en libraries, upgrades van PHP, Python, Symfony, MySQL en andere technologie, monitoring, en ingrijpen wanneer er iets fout loopt.

Daar komen in principe geen nieuwe features uit. Het is de capaciteit die verhindert dat het fundament onder je platform langzaam veroudert, en op de platformen die wij bouwen is die SLA geen optie. Hoeveel capaciteit dat vraagt hangt af van de omvang en technologie van het platform, dus werken we hier niet met één standaardpakket. Eigenaarschap en continuïteit legt uit hoe we SLA’s en continuïteit organiseren.

Sprints die het product vooruitbrengen. Nieuwe functionaliteit, verbeteringen en veranderingen aan bestaande processen blijven we bouwen in hetzelfde ritme van twee weken.

Dat je platform live staat, verandert onze manier van werken niet: we plannen, bouwen, testen, tonen en herprioriteren. Alleen komt de input er nu niet meer alleen uit plannen en aannames, maar ook uit echt gebruik.

De roadmap begint bij wat we leren

Na live krijgen gebruikers ideeën. Processen veranderen. Nieuwe klanten stellen andere eisen. Een integratiepartner verandert zijn API. Data groeit sneller dan verwacht. En sommige dingen waar tijdens discovery niemand aan twijfelde, gebruikt bijna niemand.

Daarom behandelen we een roadmap niet als een belofte voor de komende drie jaar. We kijken regelmatig samen naar wat er veranderd is, wat we geleerd hebben en waar de volgende investering het meeste oplevert. Voor grotere platformen doen we dat ieder kwartaal.

Een roadmap moet richting geven zonder te doen alsof we vandaag al weten wat over twee jaar de belangrijkste feature wordt.

AI versnelt ook de doorontwikkeling

AI maakt niet alleen de eerste bouw sneller, het verandert ook hoeveel er in een sprint past. Onze developers gebruiken het voor analyse, development, testing, refactoring en documentatie, waardoor verbeteringen sneller door het proces bewegen dan enkele jaren geleden.

Maar er gebeurt nog iets anders. AI verandert ook het platform zelf. Processen waarvoor enkele jaren geleden complexe interfaces en businesslogica nodig waren, los je vandaag soms anders op, en nieuwe modellen maken toepassingen mogelijk die bij de oorspronkelijke bouw simpelweg niet bestonden.

Daarom kijken we bij bestaande platformen regelmatig opnieuw naar de mogelijkheden. Niet iedere feature heeft AI nodig, maar een platform dat jarenlang meegaat, hoort te kunnen profiteren van technologie die tijdens zijn levensduur ontstaat.

AI zelf vraagt ook onderhoud

Wordt AI onderdeel van je product, dan ontstaat er een nieuwe vorm van technisch onderhoud. Modellen veranderen. Prijzen veranderen. Context windows groeien. Providers passen API’s aan. Een model dat vandaag de beste keuze is, kan over zes maanden te duur of voorbijgestreefd zijn.

Daarom zetten we AI-functionaliteit niet onnodig vast op één model of leverancier. We werken onder meer met Claude, OpenAI en Grok en experimenteren met zelf gehoste modellen. Groeit het AI-verbruik, dan kijken we ook kritischer naar prompts, caching, modelkeuze en tokenverbruik.

Een AI-feature is dus niet klaar omdat ze vandaag werkt. Net als de rest van een platform moet ze kunnen meegroeien.

Security stopt nooit

Een platform kan functioneel jarenlang hetzelfde blijven en technisch toch verouderen. Frameworks krijgen nieuwe versies. Libraries worden niet langer ondersteund. Nieuwe kwetsbaarheden duiken op. Authenticatiestandaarden veranderen. Externe systemen stellen nieuwe eisen.

Dat tempo is de afgelopen jaren alleen maar hoger geworden. Daarom wachten kritieke securityproblemen niet op de volgende geplande sprint: heeft een patch of kwetsbaarheid onmiddellijk aandacht nodig, dan krijgt die voorrang. Upgrades die je wel kan plannen, nemen we mee in de technische roadmap.

Onderhoud is niet wachten tot iets stukgaat. Het is ervoor zorgen dat het niet zover komt.

Integraties blijven bewegen

Je platform kan zelf stabiel zijn terwijl de wereld eromheen verandert. ERP-leveranciers brengen nieuwe versies uit. API’s worden deprecated. Payment providers veranderen authenticatie. Databronnen krijgen nieuwe structuren. Partners vervangen systemen.

Voor een platform met veel integraties is dat een permanent onderdeel van technisch onderhoud. We ontwerpen koppelingen daarom van het begin zo dat fouten zichtbaar en herstelbaar zijn, maar veranderingen aan de andere kant blijven werk vragen. Integraties legt uit hoe we daarmee omgaan.

Schaalbaarheid betekent niet bouwen voor oneindigheid

“Is het schaalbaar?” is een vraag waarop het makkelijke antwoord altijd ja is. Het nuttige antwoord is genuanceerder.

Schaalbaarheid begint bij vroege architectuurkeuzes. Hoe we data modelleren. Waar verantwoordelijkheden liggen. Welke processen asynchroon verlopen. Hoe systemen met elkaar praten. Die keuzes maken we tijdens discovery en bouw, omdat ze later duurder worden om fundamenteel te veranderen.

Maar we bouwen niet voor hypothetische oneindigheid. Een platform dat vandaag duizend transacties per dag verwerkt, hoeft niet vanaf dag één ontworpen te zijn voor honderd miljoen. Dat voegt complexiteit en kosten toe voor een probleem dat misschien nooit ontstaat.

We bouwen voor de schaal die we vandaag kennen en de groei die je redelijkerwijs verwacht, en zorgen dat de architectuur ruimte laat om verder te evolueren.

We hebben dat zelf zien gebeuren

Onze eigen platformen zijn doorheen de jaren veel groter geworden dan hun eerste versies. Medipim beheert vandaag zes miljoen producten in negen landen. Lochting draait de dagelijkse werking van zo’n 500 apotheken in vier landen, met verschillende verkoopkanalen, apparaten en integraties.

Die omvang stond niet vast toen de eerste versies gebouwd werden. Onderweg groeiden datavolumes, kwamen er landen bij, veranderden frameworks, kwamen er nieuwe koppelingen en wijzigden partners hun API’s.

Dat is voor ons de interessantere definitie van schaalbaarheid. Niet of een architectuur op papier honderd keer zoveel verkeer aankan, maar of ze kan blijven meegroeien wanneer het bedrijf iets anders van haar vraagt dan vijf jaar geleden voorzien was.

Waarom Baldwin legt uit waarom die ervaring met onze eigen producten zo zwaar doorweegt in hoe we voor klanten bouwen.

Wanneer stopt doorontwikkeling?

Dat bepaal jij. Sommige platformen krijgen continu nieuwe functionaliteit en hebben iedere sprint werk. Andere worden na enkele jaren stabieler en vragen vooral technisch onderhoud met af en toe een nieuwe feature.

We verkopen geen developmentcapaciteit omdat die toevallig gereserveerd staat. Is er minder te bouwen, dan bouwen we minder. De SLA loopt wel door, want die is niet optioneel zolang wij verantwoordelijk zijn voor het technisch gezond houden van je platform.

Vragen die we vaak krijgen

Wat gebeurt er na de lancering? Technisch onderhoud en doorontwikkeling lopen naast elkaar. Via de SLA houden we technologie, security en integraties gezond. Nieuwe functionaliteit bouwen we verder in sprints van twee weken.

Moeten we na live continu blijven ontwikkelen? Nee. Hoeveel development je nodig hebt, hangt af van het platform en je bedrijf. Sommige producten evolueren iedere sprint, andere veel minder vaak. De SLA loopt wel gewoon door.

Hoe bepalen we wat als volgende gebouwd wordt? Op basis van gebruik, feedback, bedrijfsprioriteiten en technische noden. Voor grotere platformen bekijken we de roadmap ieder kwartaal opnieuw.

Hoe schaalbaar is een platform op lange termijn? We bouwen voor de schaal en groei die je redelijkerwijs verwacht, zonder complexiteit toe te voegen voor hypothetische volumes. De architectuur zetten we zo op dat ze later kan meegroeien wanneer de werkelijkheid groter wordt dan de oorspronkelijke verwachting.

Wat zit er in de SLA? Dat bepalen we per platform. Typisch securitypatches, updates en upgrades van de gebruikte technologie, monitoring, en capaciteit om kritieke technische problemen op te lossen.

Hoe snel reageren jullie bij een kritiek probleem? Tijdens de kantooruren streven we bij klanten met een SLA naar een eerste inhoudelijke reactie binnen twee tot vier uur.

Blijven jullie ook onze integraties onderhouden? Ja. Veranderen externe API’s of systemen, dan hoort het aanpassen van die koppelingen bij het technisch gezond houden van je platform.

Hoe gaan jullie om met AI-functionaliteit die veroudert? We zetten AI-componenten zo weinig mogelijk vast op één model. We volgen kwaliteit, kosten en nieuwe mogelijkheden en passen modellen of infrastructuur aan wanneer daar een goede reden voor is.