Kort antwoord
Een Laravel-applicatie verschuift van waardevol bezit naar risico wanneer het onderhoud stilvalt. De zeven duidelijkste signalen: verouderde Laravel- en PHP-versies buiten de securitysupport, niemand die de codebase nog begrijpt, dependencies die niet meer worden bijgewerkt, een groeiende bug-backlog, features die steeds trager landen, geen monitoring en geen structureel onderhoudsafspraak. Los van elkaar zijn het ongemakken; samen maken ze je software onvoorspelbaar. Het goede nieuws: de meeste signalen zijn omkeerbaar zolang je ze op tijd herkent.
Van asset naar liability — het gebeurt geleidelijk
Bedrijfskritische software wordt zelden van de ene op de andere dag een probleem. Er is geen alarmbel die afgaat. Wat we bij Coding Agency in de praktijk zien wanneer we een bestaande Laravel-applicatie overnemen, is bijna altijd hetzelfde patroon: een applicatie die jaren trouw zijn werk deed, maar waar het onderhoud stilletjes is verwaterd. Elke afzonderlijke keuze om iets "later" te doen was verdedigbaar. Bij elkaar opgeteld is de software een risico geworden.
Het gevaarlijke aan die verschuiving is dat de software ondertussen gewoon blijft draaien. Klanten loggen in, orders komen binnen, facturen worden verstuurd. Alles lijkt in orde — tot het moment dat er iets moet veranderen, of tot het moment dat een kwetsbaarheid wordt uitgebuit. Dan blijkt de applicatie geen asset meer maar een liability: iets wat waarde onttrekt in plaats van toevoegt.
Hieronder de zeven signalen die wij als eerste toetsen. Herken je er één, dan is er meestal weinig aan de hand. Herken je er meerdere, dan is het tijd voor een gesprek over de gezondheid van je software — voordat de omgeving je die keuze opdringt.
1. Je draait op een Laravel- of PHP-versie buiten de support
Dit is het meest concrete en meetbare signaal, en tegelijk het meest onderschatte. Elke Laravel-hoofdversie krijgt volgens de officiële support policy 18 maanden bugfixes en 2 jaar securityfixes. Val je buiten dat venster van twee jaar, dan komen er geen beveiligingsupdates meer — bekende, gepubliceerde kwetsbaarheden blijven dan permanent openstaan in je framework.
Hetzelfde geldt voor de PHP-versie waarop Laravel draait: die kent zijn eigen supporttermijn. Een verouderde Laravel dwingt je vaak op een oude PHP die zelf ook geen securityupdates meer krijgt. Zo stapelt het risico dubbel op. Volgens het Verizon Data Breach Investigations Report 2025 zijn uitgebuite kwetsbaarheden inmiddels een van de grootste inbraakroutes bij datalekken — precies het risico dat je oploopt zodra je uit support valt.
Snel te checken: zoek je huidige versie op endoflife.date/laravel en endoflife.date/php. Staat er een rode datum in het verleden? Dan draai je nu zonder securitynet.
2. Niemand begrijpt de codebase nog écht
Techniek veroudert langzaam; kennis verdwijnt schoksgewijs. De developer die de applicatie bouwde is vertrokken, het bureau dat het maakte bestaat niet meer, of de documentatie zat alleen in iemands hoofd. Wat overblijft is code die draait, maar die niemand meer met vertrouwen durft aan te passen.
Dit signaal is minstens zo gevaarlijk als een verouderde versie, omdat het elk ander probleem versterkt. Een bug oplossen wordt archeologie. Een nieuwe feature toevoegen voelt als opereren in het donker. En als er iemand nodig is die "even snel" iets aanpast, blijkt dat niemand overziet wat er dan nog meer stukgaat. Een applicatie die alleen origineel te begrijpen was, is fragiel geworden — ongeacht hoe netjes de code technisch is.
Een oude maar begrepen codebase is een asset. Een moderne maar onbegrepen codebase is dat niet. Kennisborging bepaalt het verschil, niet de leeftijd van de techniek.
3. Je dependencies zijn stil komen te staan
Een Laravel-applicatie leunt zelden alleen op het framework. Er zitten tientallen community-packages onder: voor betalingen, PDF's, exports, authenticatie, queues. Die packages worden onderhouden door anderen — en volgen hun eigen ritme. Als je lang niet bijwerkt, gebeurt er iets ongemerkt: packages stoppen met het ondersteunen van jouw (oude) Laravel-versie, of worden helemaal verlaten door hun makers.
Het resultaat is een codebase die vastzit. Je kunt niet upgraden omdat package A een nieuwere Laravel vereist die package B nog niet ondersteunt. Of een package waar je kritieke functionaliteit op leunt, wordt niet meer bijgewerkt en bevat een kwetsbaarheid die nooit meer gedicht wordt. Een composer outdated die tientallen achterstallige, soms onveilige, pakketten toont is een duidelijk signaal dat het onderhoud is stilgevallen.
4. De bug-backlog groeit sneller dan hij krimpt
Elke applicatie heeft bugs. Dat is geen risicosignaal. Het signaal zit in de richting: worden er structureel meer bugs gemeld dan opgelost? Een groeiende backlog betekent dat het systeem sneller ontregelt dan het team het kan bijhouden — vaak omdat het oplossen van de ene bug een andere veroorzaakt, precies het gedrag van een codebase met opgestapelde technische schuld.
Let ook op terugkerende bugs: problemen die "opgelost" waren en toch weer opduiken. Dat wijst op een gebrek aan tests die regressies afvangen, en op een codebase waarin de gevolgen van een wijziging niet meer te overzien zijn. Wanneer het team meer tijd besteedt aan brandjes blussen dan aan vooruitgang, is de software van middel tot last verworden.
5. Nieuwe features landen steeds trager
Vraag een team hoe lang een gemiddelde nieuwe feature vroeger kostte, en hoe lang nu. Als het antwoord "veel langer" is zonder dat de features complexer zijn geworden, meet je de rente op technische schuld. Elke toevoeging vraagt eerst omwegen om bestaande fragiele code niet te breken; de codebase werkt tegen in plaats van mee.
Dit is het signaal dat management vaak als eerste voelt, zonder de oorzaak te herkennen. "Waarom duurt zo'n simpele wijziging nou zo lang?" is zelden een kwestie van luie developers — het is meestal de codebase die weerstand biedt. Tragere delivery is de bedrijfsmatige vertaling van technische verwaarlozing, en het is een van de duurste vormen ervan, omdat het je concurrentievermogen aantast zonder dat er ooit iets "kapot" gaat.
6. Je hebt geen zicht op wat er gebeurt (geen monitoring)
Draait je applicatie zonder foutmonitoring, uptime-checks of logging die iemand daadwerkelijk bekijkt? Dan hoor je van problemen via je klanten in plaats van via je systemen. Je weet niet welke fouten er dagelijks in stilte optreden, of de performance langzaam verslechtert, of dat er ongebruikelijk verkeer is dat op een aanval wijst.
Zonder monitoring is elk incident een verrassing en elke diagnose een zoektocht achteraf. Tools als Sentry voor foutmeldingen of Laravel's eigen Pulse voor performance geven het inzicht dat je nodig hebt om te acteren vóór het misgaat. Het ontbreken ervan betekent niet dat er niets aan de hand is — het betekent dat je het niet ziet. En wat je niet ziet, kun je niet beheersen.
7. Er is niemand verantwoordelijk voor onderhoud
Het laatste signaal is organisatorisch, niet technisch — en juist daarom vaak de kern. Wie is er verantwoordelijk als er morgen een kritieke security-update van Laravel uitkomt? Wie houdt de dependencies bij? Wie kijkt naar de monitoring? Als het antwoord "niemand, tenzij er iets misgaat" is, dan is onderhoud geen proces maar een reactie op incidenten.
Een applicatie zonder onderhoudsafspraak drijft onvermijdelijk af richting alle voorgaande zes signalen. Niet uit onwil, maar omdat onderhoud dat van niemand is, altijd wijkt voor werk dat wél een eigenaar heeft. Structureel beleggen van onderhoud — intern of via een vaste partner — is wat de andere zes risico's op afstand houdt. Het is niet toevallig dat dit signaal als laatste komt: los dit op, en de rest volgt vaak vanzelf.
Scorecard: hoe risicovol is jouw applicatie?
Loop de zeven signalen langs en tel hoeveel er op jouw situatie van toepassing zijn. Wees eerlijk — dit is een thermometer, geen examen.
| Signaal | Herkenbaar? |
|---|---|
| 1. Laravel of PHP buiten securitysupport | Ja / Nee |
| 2. Niemand begrijpt de codebase nog écht | Ja / Nee |
| 3. Dependencies staan stil of zijn verlaten | Ja / Nee |
| 4. Bug-backlog groeit sneller dan hij krimpt | Ja / Nee |
| 5. Nieuwe features landen steeds trager | Ja / Nee |
| 6. Geen monitoring of logging die iemand bekijkt | Ja / Nee |
| 7. Niemand is verantwoordelijk voor onderhoud | Ja / Nee |
- 0–1 signalen — Gezond. Je software is een asset. Houd het onderhoudsritme vast en blijf binnen de supportvensters.
- 2–3 signalen — Let op. Er is achterstand aan het ontstaan. Nog goed in te lopen met gericht onderhoud, maar niet iets om te laten liggen.
- 4 of meer signalen — Actie nodig. Je applicatie is van asset naar risico verschoven. Een onafhankelijke beoordeling vertelt je of het achterstallig onderhoud is of iets structureels.
De meeste risico's zijn omkeerbaar
Het geruststellende aan deze lijst is dat vrijwel alles erop te herstellen is — mits je er op tijd bij bent. Verouderde versies haal je in (kleiner en vaker is minder risicovol dan één grote sprong, zoals we uitleggen in Laravel onderhoud en upgrades). Kennis borg je met documentatie, tests en een team dat de code overneemt. Dependencies werk je bij. Monitoring zet je op in een dag. En onderhoud beleg je als doorlopend proces in plaats van als noodgreep.
De eerste stap is bijna altijd hetzelfde: een onafhankelijke second opinion of technical assessment die de werkelijke staat van de codebase, dependencies, testdekking en beveiliging in kaart brengt. Daarmee weet je of je te maken hebt met normaal achterstallig onderhoud — vervelend maar beheersbaar — of met structurele problemen die een grotere ingreep vragen. Beslissen zonder dat inzicht is gokken.
Hoe Coding Agency hierin werkt
Coding Agency is Laravel-specialist in Meppel en lid van de Dutch Laravel Foundation. Een groot deel van ons werk bestaat uit precies deze situatie: bestaande Laravel-applicaties overnemen die deze signalen zijn gaan vertonen. We beginnen met een grondige code review, brengen de software terug binnen de supportvensters, zetten tests en monitoring op, en houden de applicatie daarna op de actuele versie met een voorspelbaar onderhoudsritme.
Herken je meerdere signalen uit deze lijst, dan hoeft dat geen paniekverhaal te zijn — maar het is wél het moment om te handelen, terwijl je nog kunt kiezen. Wil je weten waar je aan toe bent? Neem contact op voor een eerlijke beoordeling van je Laravel-applicatie, of lees eerst hoe je een Laravel specialist inhuurt voor onderhoud en doorontwikkeling.
Conclusie
Een Laravel-applicatie wordt geen risico door één dramatische gebeurtenis, maar door stilstand die zich geleidelijk opstapelt: verouderde versies, verdwenen kennis, stilgevallen dependencies, groeiende bugs, tragere delivery, geen zicht en geen eigenaar voor het onderhoud. Elk signaal apart is klein; samen bepalen ze of je software waarde toevoegt of onttrekt. Herken ze op tijd, meet eerlijk met de scorecard, en behandel onderhoud als doorlopend proces — dan blijft je applicatie het bezit dat het hoort te zijn.
