Webdeveloper gezocht: waar je op let bij het inhuren

“Webdeveloper gezocht” is een zoekterm met twee soorten zoekers. De ene zoekt een vacature; voor wie een baan aanbiedt, is dit het verkeerde artikel. De andere zoekt iemand die een website bouwt of een technisch probleem oplost — en die zit met een praktischer probleem: hoe beoordeel je iemand die iets maakt dat je zelf niet kunt beoordelen?

Dat is precies de vraag die ik hier beantwoord. Ik ben zelf freelance webdeveloper — dus degene die mensen met deze vraag meestal eerst vinden. Dit is het beoordelingskader dat ik die mensen meegeef, ook als ze uiteindelijk iemand anders inhuren.

Je beoordeelt een webdeveloper op vier dingen: werk dat je kunt zien, code die iemand anders kan overnemen, referenties die je mag bellen, en een regeling voor ná de oplevering. Alles wat volgt, hangt aan die vier.

Waar vind je een goede webdeveloper

Voordat je kunt beoordelen, moet je kandidaten hebben. Drie kanalen, elk met een eigen bewijskracht:

• Je netwerk en leveranciers. Een printshop, boekhouder of copywriter die met developers samenwerkt, kent de namen die het goed doen. Een aanbeveling bewijst vooral samenwerking: iemand kwam afspraken na.
• Open source en eigen werk. Developers die bijdragen aan publieke projecten of een verzorgd eigen portfolio hebben, tonen vakmanschap en zorg — je ziet het werk zelf.
• Platforms met reviewgeschiedenis. Reviews bewijzen herhaalde tevredenheid bij verschillende opdrachtgevers. Let op de reacties op kritiek; daar lees je hoe iemand communiceert als het spannend wordt.

Geen enkel kanaal volstaat alleen. Combineer er twee: netwerk plus portfolio, of platform plus referentiegesprek.

Het portfolio zegt meer dan de prijs

Een portfolio bekijk je anders dan een prijslijst. Dit is wat ik zelf bekijk als ik werk van een collega beoordeel:

• Zijn de sites nog live? Mockups zijn presentaties; live sites zijn werkelijkheid. Open er twee of drie, klik rond, gebruik het contactformulier.
• Doen ze wat ze moeten doen? Een site hoeft geen prijs te winnen; hij moet bezoekers naar een actie brengen. Kijk of je binnen tien seconden snapt wat het bedrijf doet en wat je kunt doen.
• Hoe snel laden ze op je telefoon? Slechte snelheid is een technische tekortkoming, geen smaakkwestie. Een developer die dat laat liggen, laat meer liggen.
• Is er variatie in opdrachttypen? Vijf bijna identieke sites bewijzen één template. Een frontend-oplossing voor een verhuurder ziet er anders uit dan een webshop of een ledensite.

Vraag bij elk portfoliostuk naar de rol van de developer. Wie precies wát bouwde, en wat er van een team of klant kwam? Een eerlijk antwoord (“dat ontwerp kwam van hun eigen designer, ik heb de bouw en de koppelingen gedaan”) weegt zwaarder dan vaag claimen.

Codekwaliteit checken zonder developer te zijn

De vraag die ik het vaakst krijg: “maar hoe weet ik nu of de code goed is?” Je hoeft geen code te lezen om daar dicht bij te komen. Stel deze drie vragen:

• Werkt je met versiebeheer? Elke professionele developer werkt met Git of gelijkwaardig. “Versiebeheer” klinkt technisch, maar het betekent: elke wijziging is terug te draaien en te verantwoorden. Een nee hier is een rode vlag.
• Mag een collega de code beoordelen? Een developer die er vertrouwen in heeft, heeft daar geen probleem mee. Vraag of een andere developer het werk mag inzien of overnemen — voor een tweede mening, of voor het geval jullie later uit elkaar gaan.
• Kan een ander dit later overnemen? Vraag het letterlijk zo. Het antwoord onthult of je een CMS of framework krijgt dat breed gebruikt wordt, of een eigen bouwsel dat alleen de bouwer zelf begrijpt. Dat laatste heet lock-in, en het is een van de drie valkuilen hieronder.

Na de oplevering merk je het verschil pas echt. Vraag daarom naar een recente site van een jaar oud en bekijk hoe die nu presteert en wie hem onderhoudt.

Referenties: wat je echt vraagt

Bijna iedereen vraagt referenties; bijna niemand stelt de goede vragen. “Was het tevreden?” krijgt altijd ja. Dit zijn de drie vragen die iets blootleggen:

• Hoe verliep de communicatie toen iets vertraging opliep? Elk project kent wrijving. Je wilt weten hoe het ging toen het spannend werd, niet of het perfect verliep.
• Wat gebeurde er ná de oplevering? Kreeg je antwoord binnen enkele dagen, of verdween de developer achter een Support-formulier? Ondersteuning na oplevering is een hoofdstuk apart, hieronder.
• Zou je deze developer opnieuw inhuren voor een groter project? Die vraag dwingt tot een afweging tussen prijs, comfort en vertrouwen, en levert eerlijkere antwoorden op dan een tevredenheidscijfer.

Eén referentiegesprek van tien minuten zegt meer dan tien pagina’s reviews.

Wat goede communicatie verraadt

Je kunt niet aan code aflezen of een samenwerking prettig verloopt, maar aan communicatie wél. Drie signalen die ik zou checken:

• Vaste momenten. Een wekelijkse korte update of een vast overstrijkt moment werkt beter dan “ik hoor wel iets als het klaar is”. Vraag hoe de developer rapporteert.
• Vragen terug. Een goede webdeveloper inhuren betekent dat er vragen terugkomen over je doelen, je klanten en je content. Wie alleen bevestigt wat je zegt, bouwt jouw aannames in plaats van je site.
• Een plan met tussenstations. Eén einddatum is een gok; een reeks tussenstations — ontwerp, eerste versie, testen, live — is een plan. Je kunt bij elk station bijsturen voordat alles af is.

Communicatie is geen soft skill hier. Bij een technisch traject van enkele weken of maanden is het de enige manier waarop je als opdrachtgever grip houdt.

Ondersteuning ná de oplevering

Websites zijn geen eenmalige levering. Plugins, frameworks en hosting evolueren door, en je eigen content ook. Bespreek daarom vóór de start wat er ná de lancering gebeurt. Ik noem dat websiteonderhoud, en het omvat minstens:

• Wie bezit wat? Code, domein, hostingaccount: vraag expliciet wiens naam erop staat en zorg dat jij de eigenaar bent. Je wil van developer kunnen wisselen zonder om toestemming te vragen.
• Wat dekt de regeling? Updates, back-ups, beveiliging, kleine wijzigingen: leg vast wat erbij hoort en wat doorloopt tegen een afgesproken tarief.
• Hoe wordt gemeten? Afspraken over conversie of snelheid zijn pas eerlijk als er ook gemeten wordt. Vraag om een nulmeting vóór de bouw en periodieke metingen erna, zodat je weet of de site doet wat ze beloofde.

Een developer die dit gesprek vermijdt, verdwijnt na de oplevering. Eén die het zelf aansnijdt, denkt na over jouw site van over een jaar.

Drie valkuilen bij het inhuren

Na meer dan 25 jaar bouwen heb ik deze drie het vaakst langs zien komen — telkens bij klanten die er net naast zaten:

• De goedkoopste optie. De laagste prijs is zelden de laagste kost. Een site die na een jaar opnieuw moet, is duurder dan één die meteen goed zat. Vergelijk offertes op scope, niet op bedrag.
• Geen onderhoudsregeling. “Laten we dat later bekijken” betekent in de praktijk: niet. Een site zonder update-afspraak veroudert stilletjes, en de reparatie achteraf is groter dan het onderhoud ervoor.
• Vendor lock-in. Maatwerk dat alleen de bouwer begrijpt, lijkt zorg op maat maar is een relatie zonder uitgang. Vraag of een andere developer het werk kan overnemen, en neem “nee, dat is ons systeem” serieus als antwoord.

De drie valkuilen hebben één gemeenschappelijke geneesmiddel: schrijf scope, eigendom en onderhoud op vóór de start. Een A4 is genoeg.

Twijfel je tussen een webdesigner en een webdeveloper?

Veel zoekers in de fase “webdeveloper gezocht” bleven ergens anders naar op zoek. Als je vooral twijfelt over wíe je nodig hebt — de vormgeving of de techniek — dan is de vraag niet “wie is beter”, maar “wat moet er precies gebeuren”. Voor een voornamelijk visuele opdracht lees je meer over de aanpak van een freelance webontwikkelaar versus die van een freelance webdesigner; de profielen vullen elkaar aan en overlappen minder dan de termen suggereren.

Twijfel je vooral over het budget? De kaders en prijsbepalers van een website staan in wat kost een website laten maken — wat hierboven geldt voor het beoordelen van een developer, geldt daar voor het beoordelen van een offerte.

En wil je liever één aanspreekpunt dat van intake tot ux en onderhoud loopt? Lees dan hoe wij een website laten maken aanpakken — maar de vragen uit deze gids mag je ons evengoed stellen.