Freelance Drupal developer inhuren

Een freelance Drupal developer inhuren is een capaciteitsbeslissing, geen noodgreep.
Er loopt een project, het team heeft de Drupal-diepgang niet in huis en er is geen half jaar om iemand aan te werven.
Ik ben David Porschmann, freelance Drupal-architect met meer dan tien jaar ervaring.
Ik werk vanuit Herk-de-Stad in Limburg voor opdrachtgevers in Belgie en Nederland, remote in CET, in het Nederlands of het Engels.
Zit je zelf in de regio, dan lees je op freelance Drupal developer in Limburg hoe dat lokaal loopt.
Hieronder staat hoe inhuren verloopt, wat het kost en wanneer je beter iemand anders neemt.

Wanneer huur je een freelance Drupal developer in?

Inhuren is zinvol wanneer het werk senior is maar niet permanent.
Een vaste senior aanwerven kost maanden zoekwerk en levert een kostenpost die blijft staan wanneer het project af is.
Voor een afgebakend traject, een piek in de planning of een rol als technisch lead op één project is een contractor de snellere route.

• ✓ Je hebt een Drupal-project verkocht en de planning loopt vast op capaciteit, niet op scope.
• ✓ Je team bouwt goed in Drupal maar mist iemand die de architectuurkeuzes onderbouwt en de code review draagt.
• ✓ Er staat een migratie naar Drupal 11 op de planning en niemand in het team heeft er eerder een gedaan.
• ✓ Een bedrijfskritische site geeft problemen die niemand tot de oorzaak terugbrengt.
• ✓ Je senior vertrekt en de kennis mag niet met hem de deur uit.

Voor een volledig nieuw platform van architectuur tot oplevering is Drupal architectuur en ontwikkeling de betere ingang.
Gaat het om doorlopend onderhoud met een vast urenpakket, kijk dan bij technisch beheer en consultancy of bij Drupal onderhoud en support.

Wat een senior contractor toevoegt aan een bestaand team

Een senior contractor voegt beslissingen toe, niet alleen handen.
Extra handen regel je met een willekeurige developer en dan verschuift het knelpunt naar wie het werk moet nakijken.
Waar een team op vastloopt is meestal niet het volume, maar de keuze die niemand met genoeg zekerheid durft te maken.

Architectuurkeuzes onderbouwen

Of iets een custom entity wordt of een node met velden, of een view volstaat of je een eigen query nodig hebt, of die functionaliteit al in contrib bestaat: die keuzes bepalen wat je er over twee jaar aan onderhoudt.
Ik breng de opties in kaart, noem de kost van elk pad en leg de beslissing vast waar je team ze terugvindt.

Code review en standaarden

Code review is de plek waar een junior team het snelst groeit en de eerste taak die sneuvelt onder deadlinedruk.
Ik neem deel aan de reviews die er al zijn, met de coding standards van Drupal als referentie en met PHPStan en PHP CodeSniffer in de pipeline in plaats van in een discussie.

Escalaties en oude codebases

Een vreemde codebase snel doorgronden hoort bij het werk.
Bij een escalatie is de eerste opdracht niet patchen maar reproduceren, want een bug die je niet kan reproduceren komt terug.
De sites voor universiteiten, overheid en industrie waar dat aan de orde was staan bij de projecten.

Beschikbaarheid en opstarttijd: vraag het op, veronderstel het niet

Beschikbaarheid is de eerste vraag die je stelt, niet de laatste.
Ik werk niet aan vijf trajecten tegelijk, dus een nieuwe opdracht past in de ruimte die er is.
In de praktijk start een afgebakende opdracht meestal binnen enkele weken en een acute escalatie sneller wanneer die voorgaat op werk dat kan wachten.

De opstarttijd zelf is korter dan de meeste teams verwachten, maar niet nul.
Een dag om de codebase, de deploystrategie en de conventies te lezen is normaal.
Lukt dat niet in een dag, dan zegt dat iets over de staat van het project en dat is meteen de eerste bevinding die je krijgt.

Voor het najaar van 2026 is er één planningsfactor die je meeneemt.
Drupal 10 bereikt end of life op 9 december 2026, met 10.6.0 als laatste minor release en Drupal 12 wordt uitgebracht in de week van 7 december 2026.
Wie in november nog op Drupal 10 zit, concurreert dus om capaciteit met iedereen die op hetzelfde moment tot dezelfde conclusie komt.
Voor dat werk is Drupal migratie en upgrade de specifieke pagina.

Samenwerken met een bestaand dev-team en je Git-flow

Ik stap in de flow die er staat, ik zet er geen tweede naast.
Dat betekent jullie branchingmodel, jullie merge requests, jullie definition of done en jullie releasemomenten.
Een contractor die zijn eigen werkwijze meebrengt, levert code op die niemand daarna durft aan te raken.

• Branches en reviews: feature branches op jullie conventie, elke wijziging via een merge request, ook de kleine.
• Configuratie in code: alles via config management en Composer, geen wijzigingen die alleen op productie bestaan.
• Deploys: jullie pipeline en jullie omgevingen, met een update hook in plaats van handwerk in de database.
• Overleg: een korte stand-up of een schriftelijke update per dag, want asynchroon werken vraagt meer schrijven dan bellen.
• Overdracht: wat ik beslis staat in de repo of in jullie documentatie, niet alleen in mijn hoofd.

Ben je een agency die de klantrelatie zelf houdt, dan blijf ik als onderaannemer achter de schermen.
Dat is een aanzienlijk deel van mijn werk en mijn naam hoeft nergens op te duiken.

Rechtstreeks inhuren of via een detacheerder?

Rechtstreeks inhuren is goedkoper, want er zit geen marge tussen.
Een detacheerder of broker rekent een opslag op het tarief dat de developer werkelijk ontvangt.
Hoeveel die opslag is, staat zelden in het contract dat jij ziet en dat is een redelijke vraag voor je een raamcontract aftekent.

Een detacheerder is niet per definitie de verkeerde keuze.
Mag je organisatie alleen via goedgekeurde leveranciers inkopen, of heb je vijf rollen tegelijk nodig, dan is één contractpartij dat geld waard.
Voor één senior op één traject betaal je die marge zonder er iets voor terug te krijgen.
Ik werk in beide constructies.

Wat kost het om een freelance Drupal developer in te huren?

Mijn tarief is 75 tot 95 euro per uur, of 650 tot 800 euro per dag, exclusief btw.
Waar je in die bandbreedte valt hangt af van de looptijd en de aard van het werk: bij lange trajecten en bij terugkerende opdrachtgevers ligt het lager.
De volledige opbouw staat op de pagina tarieven.

Mijn dagtarief ligt boven die Drupal-mediaan.
Die mediaan bundelt vermoedelijk heel verschillende rollen, van sitebuilding en theming tot architectuur en dat verklaart een deel van het verschil.
Voor Nederland noemt Freelance.nl 70 tot 90 euro per uur, wat dichter bij mijn uurtarief ligt.

Een lager tarief is daarmee niet automatisch goedkoper.
Voor standaard sitebuilding is een tarief onder mijn bandbreedte verstandig besteed geld.
Voor de beslissing of je datamodel deze migratie overleeft, betaal je de uren die je vooraan uitspaart later aan de tweede poging.
Hoe die marktcijfers tot stand komen en waarom de verschillen zo groot zijn, staat uitgewerkt in wat een freelance Drupal developer kost in 2026.

Wat er nodig is om snel productief te zijn

De eerste week win of verlies je op toegang, niet op talent.
Dit is wat er klaar moet staan:

1. Repo-toegang en een README: een Git-account en een beschrijving waarmee de site lokaal draait.
   Mijn eigen werk staat op GitHub en op drupal.org.
2. Een werkende lokale omgeving: Docker of Lando met een recente databasedump, geanonimiseerd waar dat moet.
3. Een staging-omgeving en het deploypad: waar je naartoe deployt, wie op de knop drukt en wat er terugrolt bij een fout.
4. Eén inhoudelijk aanspreekpunt: iemand die vragen over functionaliteit binnen een dag beantwoordt.
   Dit is in de praktijk het vaakst de ontbrekende schakel.
5. De backlog met prioriteiten: niet de volledige wensenlijst, maar wat er deze sprint moet gebeuren en waarom.
6. Toegang tot logs en monitoring: bij een escalatie is dit het verschil tussen diagnose en gokwerk.

Ontbreekt de helft van dit lijstje, dan is dat geen blokkade.
Het betekent dat de eerste dagen deels naar de omgeving gaan en dat je dat beter weet voor de opdracht begint dan erna.

Versies en normen waarop ik werk

Drupal 11 is de huidige stabiele versie, met 11.4.x als actuele reeks.
Drupal 9 valt buiten support sinds november 2023, Drupal 8 sinds november 2021 en Drupal 7 sinds 5 januari 2025, dus die drie pak ik op als migratietraject en niet als doorontwikkeling.
Draait er nog een Drupal 7-site, lees dan wat je daar nu mee moet.
De European Accessibility Act, richtlijn 2019/882, is van toepassing sinds 28 juni 2025, maar niet op elke website.
De richtlijn viseert een afgebakende groep producten en diensten, waaronder e-commerce, bankieren en verzekeren, personenvervoer, telecom, e-books en audiovisuele mediadiensten en de nationale omzetting in Belgie en Nederland bepaalt wat er precies onder valt en vanaf wanneer.
Overheidssites vallen al langer onder richtlijn 2016/2102.
Valt jouw site onder een van die regimes, dan zijn WCAG 2.2 niveau AA en EN 301 549 in de praktijk de normen waarmee je componenten toetst.
Of dat bij jou zo is, lees je in geldt de European Accessibility Act voor jouw website.
Dat is codewerk, geen plug-in en het staat op digitale toegankelijkheid.

Drupal-capaciteit nodig op een lopend traject?