Maarten
PHP developer
PHP · Laravel · WordPress · API's
PHP developer
PHP developer inhuren voor Laravel, WordPress of een verouderde codebase: freelance, met 25 jaar ervaring, vanuit Nijmegen en remote door heel Nederland. Hulp zit in het stuk dat het meeste pijn doet, niet in een verplichte rewrite.
Eerder gebouwd voor Autovisie, Telvero en de Evangelische Omroep.
Eén ervaren freelancer
PHP developer inhuren voor je codebase
Korte audit van je codebase, de grootste pijnpunten en de snelste route vooruit. Modernisering zonder big-bang, een nieuwe build met testdekking, of iemand die je legacy systeem niet bang is aan te raken. Vooraf is er een gesprek nodig om te weten wat er speelt, niet andersom.
- Codebase- en architectuur-audit
- Aanpak zonder big-bang migratie
- Concreet voorstel in fases
- Direct contact, geen tussenlagen
Waarom een PHP developer inhuren de juiste keuze is
PHP is het framework van vlak voor gisteren, hoor je weleens, maar de praktijk is anders: onder een groot deel van de Nederlandse webshops, contentplatformen en interne applicaties draait nog altijd PHP, vaak in de vorm van WordPress, WooCommerce of een eigen Laravel-backend. Dat is geen toeval. Weinig talen zijn zo breed inzetbaar, zo goed gedocumenteerd en zo eenvoudig te hosten, en dat maakt PHP nog steeds een verdedigbare keuze voor bedrijven die niet elk jaar een nieuwe stack willen leren beheren. Het probleem zit zelden in de taal zelf, maar in de laag eromheen: verouderde dependencies, ontbrekende tests, een database die is meegegroeid zonder ooit opnieuw bekeken te zijn, of een koppeling die is gebouwd voor een situatie die inmiddels is veranderd.
Een freelance PHP developer inhuren betekent, in de praktijk, iemand die zowel de taal kent als de context eromheen: hosting, caching, databases, API-koppelingen en de eigenaardigheden van WordPress- of Laravel-projecten die al jaren meelopen. Vanuit Nijmegen wordt er gewerkt voor opdrachtgevers door heel Nederland, meestal op afstand en af en toe op locatie voor een sessie met het team. Vijfentwintig jaar PHP betekent ook: genoeg codebases gezien om te weten dat de snelste oplossing niet altijd de beste is, en dat een volledige rewrite bijna nooit de eerste stap hoort te zijn. Vaker gaat het om een gerichte ingreep op het onderdeel dat het meeste pijn doet, terwijl de rest van het systeem intussen gewoon door blijft draaien.
Elk traject begint met dezelfde vraag: wat werkt hier eigenlijk, en wat is het onderliggende probleem? Een codebase-audit brengt dat in kaart, van databaseontwerp tot de plekken waar foutafhandeling ontbreekt. Op basis daarvan ontstaat een aanpak die past bij de situatie: een WordPress-site die is doorgegroeid tot buiten wat het thema aankan, een WooCommerce-shop die aan marketplaces gekoppeld moet worden, of een Laravel-applicatie die eerst testdekking nodig heeft voordat er nieuwe functionaliteit bij komt. Soms betekent dat een paar dagen gericht werk, soms een langer traject in fases. Wat niet verandert, is de manier van werken: kleine, controleerbare stappen in plaats van één groot risico ineens.
Voor wie dit werkt, loopt uiteen: een webshopeigenaar wiens WooCommerce-omgeving is doorgegroeid tot buiten het comfortabele, een IT-afdeling die tijdelijk extra PHP-capaciteit nodig heeft naast het eigen team, of een bureau dat een deel van de bouw uitbesteedt en zelf de klantrelatie houdt. In alle gevallen gaat het om dezelfde behoefte: een developer die de taal, het framework en de manier van samenwerken kent, zonder daar een account manager en een langdurig sales-traject tussen te zetten.
Wat een PHP-project precies nodig heeft, is zonder de code gezien lastig te zeggen. Daarom begint het meestal met een kennismakingsgesprek: een half uur om te horen wat er speelt, gevolgd door een eerlijk beeld van waar het project staat en welke vervolgstappen logisch zijn. Geen verplichting, en geen verkooppraatje over een oplossing die nog niet is onderzocht.
Gebouwd voor
Klaar om je codebase weer onder controle te krijgen?
Wat een PHP developer oplevert
Zelden is een complete rewrite de oplossing; meestal levert een gerichte ingreep op het onderdeel met de meeste pijn al het meeste op, zonder de rest van het systeem te hoeven aanraken. Een paar voorbeelden van wat er dan concreet verandert.
-
Legacy code weer onder controle
Een audit brengt eerst in kaart wat een oude PHP-versie zonder tests daadwerkelijk doet, zodat een wijziging geen gok meer is, ook als de developer die het ooit bouwde niet meer te bereiken is.
-
Een snellere backend
Profilering laat zien waar de tijd bij trage paginas en wegklikkende foutmeldingen echt naartoe gaat: vaak een paar zware queries, zelden de servergrootte.
-
Stabiele API-koppelingen
Een timeout en nette foutafhandeling zorgen dat een trage externe API de rest van de site niet meesleept, in plaats van dat één partij de hele applicatie raakt.
-
Een WordPress- of WooCommerce-shop die weer soepel loopt
Gericht opschonen en herstructureren van de plug-ins en het thema die tegen hun grenzen aanlopen, meestal zonder de hele shop over te hoeven zetten.
-
Testdekking die een release veilig maakt
Tests rond de belangrijkste flows maken een release een routinehandeling in plaats van een gok over wat er breekt en hoeveel tijd het bugfixen gaat kosten.
-
Advies over doorbouwen of legacy vervangen
Verder bouwen op de bestaande PHP-codebase, in fases moderniseren of toch een nieuwe backend: een codebase-audit brengt in kaart wat haalbaar is, zodat de keuze niet op onderbuikgevoel wordt gemaakt maar op wat er in de code werkelijk staat.
Benieuwd wat een korte audit van jouw codebase oplevert?
PHP dat grote bezoekersaantallen aankan
Niet elke WordPress-site hoeft klein te blijven. Voor Autovisie, onderdeel van Telegraaf Mediagroep, is een online autoplatform gebouwd inclusief abonnementenmodel en een redactieomgeving die het werk van de redactie eenvoudig maakt. De uitdaging zat niet in WordPress zelf, maar in de combinatie: veel bezoekers, veel content, een prettige leeservaring op elk scherm en een redactie die zonder hulp van een developer moet kunnen publiceren.
Dat is precies het werk dat bij WordPress vaak onderschat wordt: het thema en de plug-ins zijn het zichtbare deel, maar de caching-strategie, de querybelasting en de manier waarop content wordt opgebouwd bepalen of een site onder drukte overeind blijft. Bij een platform dat moet meegroeien is dat fundament minstens zo belangrijk als het ontwerp dat erboven op staat.
Diezelfde denkwijze geldt voor kleinere WordPress-sites die nog niet tegen hun grenzen zijn aangelopen: liever het fundament op orde voordat het bezoekersaantal verdubbelt, dan achteraf onder tijdsdruk uitzoeken welke plug-in de boel vertraagt.
PHP-koppelingen naar marketplaces
Voor Telvero is de bestaande webshop doorontwikkeld en gekoppeld aan marketplaces via Channable, zodat het assortiment op meer plekken zichtbaar werd. Dat soort koppelingen klinkt eenvoudig, tot een marketplace een ander voorraadformaat verwacht, een prijswijziging vertraagd doorkomt of een synchronisatie halverwege vastloopt.
De winst zit in de details rond de koppeling zelf: nette foutafhandeling als een marketplace traag reageert, een duidelijk logboek van wat er is gesynchroniseerd, en een winkelervaring die ondertussen op elk scherm soepel blijft. WooCommerce is daarbij het uitgangspunt, niet het eindpunt: de koppeling eromheen bepaalt of extra verkoopkanalen ook echt extra rust opleveren in plaats van extra beheerwerk.
Hetzelfde patroon komt terug bij koppelingen met een ERP-systeem of een betaalprovider: de vraag is zelden of de koppeling in de gelukkige route werkt, maar wat er gebeurt op de dag dat dat niet zo is.
Twijfel over de volgende stap? Een half uur meedenken helpt vaak al.
PHP-werk dat regelmatig terugkomt
Van een nieuwe Laravel-backend tot een WordPress-installatie die aan zijn plafond zit: onderstaand het werk dat het vaakst terugkomt, telkens toegesneden op de codebase die er al ligt.
Laravel-backends
Schoon opgezet, met aandacht voor naming, structuur en foutafhandeling in plaats van alles in de controller. Zo blijft de codebase ook voor een ander te volgen.
WordPress & WooCommerce maatwerk
Thema- en plug-inwerk, custom functionaliteit en het oplossen van prestatieproblemen op een bestaande installatie, zonder de site onnodig op de schop te nemen.
API-koppelingen
REST-koppelingen tussen je systemen, met nette authenticatie en afhandeling van de foutpaden voor het moment dat de andere kant even niet meewerkt.
Databasewerk
Schemaontwerp, indexen en query-optimalisatie op MySQL, PostgreSQL of Supabase, met oog voor hoe de data over een paar jaar nog gebruikt wordt.
Legacy modernisering
Stap voor stap doorontwikkelen van een oudere codebase, zodat de winkel of applicatie intussen gewoon door blijft draaien in plaats van maandenlang plat te liggen.
Testdekking opbouwen
Tests rond de onderdelen die het bedrijf raken als ze breken, zodat een release geen gok meer is en een refactor met vertrouwen kan.
- PHP
- Laravel
- WordPress
- WooCommerce
- Magento
- MySQL
- PostgreSQL
- Supabase
- PDO
- REST
- Webhooks
- Git
Veelgestelde vragen
Een aantal vragen dat regelmatig terugkomt bij het inhuren van een PHP developer, van framework-keuze tot testdekking. Staat je eigen vraag er niet bij, stel 'm gewoon in het kennismakingsgesprek.
Werk je met Laravel, WordPress of iets anders?
Met beide, en ook met losse PHP zonder framework als dat past bij wat er al draait. De keuze hangt af van het project en van wie het straks beheert, niet van een voorkeur voor een bepaald framework. Bij een bestaande installatie is doorbouwen op wat er staat meestal verstandiger dan overstappen, tenzij het fundament daar simpelweg niet geschikt meer voor is.
Kun je een bestaand PHP-project overnemen?
Meestal wel. Eerst een korte audit van de codebase, om te zien wat er speelt, hoe de documentatie ervoor staat, welke dependencies verouderd zijn en waar de risico's echt zitten. Die audit maakt ook duidelijk wie de oorspronkelijke keuzes heeft gemaakt en waarom, iets wat bij een overname zonder documentatie vaak het meeste tijd kost om te achterhalen. Daarna volgt een gefaseerde aanpak in plaats van een big-bang herbouw: eerst de plekken aanpakken die het meeste risico of de meeste pijn opleveren, terwijl de winkel of applicatie intussen gewoon door blijft draaien. Testdekking rond de belangrijkste flows wordt meestal als eerste toegevoegd, zodat een volgende wijziging geen gok meer is. Zo blijft de overname beheersbaar, ook als de vorige developer niet meer te bereiken is.
Bouw je ook nieuwe API-koppelingen?
Ja, REST-koppelingen tussen systemen, inclusief de foutafhandeling voor het moment dat de andere kant traag is of niet reageert. Denk aan koppelingen met marketplaces, ERP-systemen of betaalproviders, met logging zodat een storing achteraf te herleiden is.
Werk je met testdekking?
Standaard rond de onderdelen die er het meeste toe doen, met PHPUnit of Pest, en altijd eerst tests om bestaande code heen voordat die verandert. Dat is met name bij legacy code de manier om veilig te kunnen wijzigen zonder verrassingen op productie.
Wat als de site of shop traag is?
Eerst uitzoeken waar de tijd echt naartoe gaat: trage queries, ontbrekende caching of te veel losse aanroepen naar externe diensten. Vaak is dat op te lossen zonder een grotere server, door het probleem bij de bron aan te pakken in plaats van meer rekenkracht te kopen die het onderliggende probleem alleen maar verbergt.
Wat kost een PHP-traject?
Dat hangt af van de omvang en de vorm: een uurtarief of een vaste prijs per fase. Bij een kortlopende klus, zoals een gerichte bugfix of een kleine uitbreiding, past een uurtarief meestal beter; bij een groter traject met meerdere fases geeft een vaste prijs per fase meer houvast vooraf. De eerste stap is bijna altijd een codebase-audit, waarin duidelijk wordt hoe groot het probleem werkelijk is, welke onderdelen risico lopen en hoeveel werk een gezonde oplossing vraagt. Pas na die audit ontstaat een concreet beeld van de omvang, waarna je zelf beslist of en hoe je verder gaat. Er zit geen verplichting aan een audit vast, en geen vast pakket dat wordt aangeboden ongeacht wat de codebase daadwerkelijk nodig heeft.
PHP-project dat beter moet?
Een half uur bellen om de codebase en de knelpunten te bespreken, en of doorontwikkelen of opnieuw beginnen de logische route is. Geen verplichting, en ook geen kant-en-klaar advies voordat er is meegekeken.