Hoe "één API-call" uitgroeit tot een zelfgebouwd framework
Elke vanilla PHP-integratie begint met dezelfde belofte: "Het zijn maar een paar API-calls." Drie integraties later heb je je eigen router, errorhandler en configmanager gebouwd — en niemand anders kan het onderhouden.
"We moeten alleen Stripe aansluiten — een paar API-calls, niets ingewikkelds." Je hebt deze zin vast wel eens gehoord. Misschien heb je hem zelf uitgesproken. En op dat moment klopt het: een betalingsintegratie in vanilla PHP kan in een paar honderd regels. Het werkt. Je levert op. Iedereen blij.
Dan komt het tweede verzoek. Dan het derde. En ergens rond het vierde besef je dat je geen features meer toevoegt — je bouwt infrastructuur.
Fase één: "Gewoon een betaalformulier"
Een Stripe-integratie vereist een HTTP-client, foutafhandeling voor 20+ fouttypen, retry-logica met exponentiële backoff en webhookverwerking met handtekeningverificatie. Je schrijft helperklassen, een kleine configlader, misschien een simpele logger. Een paar honderd regels worden er duizend. Maar het werkt, dus je gaat door.
Fase twee: "Sluit nu ook het CRM aan"
Weer een API, weer een HTTP-client wrapper. Maar deze heeft OAuth2-tokenbeheer, ververslogica en rate limiting nodig. De foutafhandelingspatronen zijn anders dan bij Stripe — dus bouw je een "basis API-client" klasse om ze te verenigen. Je hebt zojuist een servicelaag gecreëerd.
De configlader uit fase één was niet ontworpen voor meerdere integraties. Je breidt hem uit. Nu leest hij omgevingsvariabelen, heeft hij per-omgeving overrides en ondersteunt hij secrets. Je hebt een configuratiemanager gebouwd.
Fase drie: "Voeg een klantenportaal toe"
Gebruikers moeten inloggen, documenten uploaden en hun betalingshistorie bekijken. Dat betekent:
- Authenticatie — sessiebeheer, wachtwoord-hashing, "onthoud mij"-tokens
- CSRF-bescherming — tokengeneratie en -verificatie op elk formulier
- Bestandsuploads — MIME-validatie, path traversal-preventie, opslagabstractie
- Routing — nette URL's voor /login, /dashboard, /documenten, plus je bestaande webhook-endpoints
Elk van deze problemen is opgelost in elk modern framework. In vanilla PHP is elk ervan een week werk, een week testen die je waarschijnlijk overslaat, en een permanente onderhoudsverplichting.
Fase vier: "Er moet achtergrondverwerking bij"
Webhook-retries, e-mailverzending en CRM-synchronisatie kunnen niet in een webrequest draaien. Je hebt een jobqueue nodig, een CLI-ingang, een cronplanner. Inmiddels heeft je project een eigen router, middleware-pipeline, servicecontainer, configmanager, ORM-achtige querybuilder, achtergrondworker en CLI-tool.
Gefeliciteerd — je hebt maanden besteed aan het bouwen van een framework. Alleen heeft het jouwe nul documentatie, nul tests, nul community en precies één persoon die het begrijpt.
Dit is geen theorie — de data bevestigt het
CAST analyseerde 10 miljard regels productiecode in verschillende sectoren in 2025. De bevindingen zijn ongemakkelijk:
45% van alle productiecode is fragiel — vatbaar voor fouten onder onverwachte omstandigheden. 32% is opgeblazen. 31% is te rigide om veilig aan te passen. Aangepaste codebases zonder frameworkwaarborgen, geautomatiseerde testcultuur of door de community beoordeelde architectuur scoren op elke maatstaf slechter.
En de bedrijfskosten zijn reëel. McKinsey Digital stelde in 2024 vast dat features op codebases met hoge technische schuld 2 tot 3 keer langer duren om op te leveren:
Een feature die in Laravel 2 weken kost, kost 4 tot 6 weken op een codebase met hoge schuld. Dat is geen kwestie van ontwikkelaarsvaardigheid — het zijn de kosten van vechten tegen je eigen infrastructuur in plaats van bouwen op bewezen fundamenten.
De legacy-val is groter dan je denkt
Volgens W3Techs-data van maart 2026 draait 43% van de PHP-websites nog op end-of-life PHP-versies — geen beveiligingspatches, geen prestatieverbeteringen, geen upgradepad.
Dit zijn geen Laravel- of Symfony-projecten. Framework-ecosystemen duwen teams richting actuele PHP-versies via afhankelijkheidsvereisten en tools zoals Laravel Shift. De 43% die EOL-PHP draait, zijn overwegend vanilla codebases — precies het type dat zelfgebouwde infrastructuur ophoopt.
Wat het ecosysteem allang heeft opgelost
Elke infrastructuurlaag die je met de hand zou bouwen, bestaat al als getest, gedocumenteerd en door de community onderhouden pakket. Packagist — het PHP-pakketregister — bevat 445.000+ pakketten met 172 miljard totale installaties. Alleen al Guzzle (de HTTP-client die je als eerste zou herbouwen) heeft meer dan 925 miljoen downloads.
Dit is wat een framework je standaard biedt — gratis:
- Routing en middleware — URL-afhandeling, auth-checks, rate limiting, CORS
- Beveiliging — CSRF-tokens, SQL-injectiepreventie, XSS-escaping, versleutelde sessies
- Database — querybuilder, migraties, relaties, connection pooling
- Wachtrijen en planning — achtergrondjobs, retries, cronbeheer
- Testen — ingebouwde testrunner, factories, assertions, HTTP-testing
Niets hiervan is "overkill." Het is de minimale infrastructuur voor elk project dat betalingen, API's of gebruikersdata verwerkt. De enige vraag is of je het zelf bouwt of een versie gebruikt die duizenden ontwikkelaars al hebben doorgetest.
De echte kosten zijn niet technisch — ze zijn organisatorisch
Wanneer de ontwikkelaar die je aangepaste infrastructuur heeft gebouwd vertrekt, vertrekt de kennis mee. Het inwerken van een vervanger op een standaard framework duurt weken. Inwerken op een zelfgebouwd systeem zonder documentatie? Dat zijn maanden — als het überhaupt lukt.
64% van de PHP-ontwikkelaars kent al Laravel (JetBrains, 2025). Dat is een wervingspool waar je direct uit kunt putten. Een eigen codebase beperkt je tot ontwikkelaars die bereid zijn een ongedocumenteerd systeem te leren zonder carrièrewaarde.
Wat te doen als je er al middenin zit
Als dit herkenbaar klinkt, zit je niet vast — maar hoe langer je wacht, hoe duurder de uitweg wordt. Een paar praktische stappen:
- Breng in kaart wat je hebt gebouwd. Inventariseer elk stuk aangepaste infrastructuur: routing, auth, config, wachtrijen. Vergelijk het met wat een framework standaard biedt.
- Stop met het uitbreiden van het zelfgebouwde systeem. Elke nieuwe feature op aangepaste infrastructuur verhoogt de migratiekosten.
- Migreer stapsgewijs. Het Strangler Fig-patroon — legacy code stuk voor stuk omwikkelen met frameworkcomponenten — is veiliger en goedkoper dan een volledige herschrijving.
- Vraag een externe beoordeling aan. Iemand buiten je team kan architecturele schuld herkennen die onzichtbaar is geworden voor degenen die er dagelijks in werken.
Herkenbaar?
Laat ons de gezondheid van je codebase beoordelen
Als je PHP-project laag na laag zelfgebouwde infrastructuur heeft opgestapeld, kunnen wij de schuld in kaart brengen en een realistisch migratiepad uitstippelen — voordat de volgende "kleine integratie" het erger maakt.