Stel: je hebt dezelfde opdracht. Een login-flow uitbreiden, een API-koppeling, of een kleine feature in je SaaS. Developer A rekent €120 per uur en is klaar in 3 uur. Developer B rekent €80 per uur en doet er 6 uur over.
De facturen:
- Developer A: 3 × €120 = €360
- Developer B: 6 × €80 = €480
Developer A is dus €120 goedkoper op deze opdracht — en is vaak ook sneller klaar. Toch kiezen veel ondernemers automatisch B: "€80 per uur klinkt voordeliger." Dat is de denkfout: uurtarief ≠ projectprijs ≠ waarde.
Wie alleen naar het uurtarief kijkt, betaalt soms meer, krijgt minder, en bouwt rework in. Benchmarken betekent vergelijken op wat je overhoudt — en wat het je daarna kost.
Dit artikel is het vervolg op developers benchmarken en uurtarief versus tarief per feature. Hier rekenen we niet op gevoel, maar op zes concrete criteria die je zelf kunt toetsen.
Het scenario
De opdracht is bewust herkenbaar — geen toy project, geen fizzbuzz:
- Doel: bestaande klanten kunnen een extra gebruiker uitnodigen in hun account
- Context: Angular frontend, Node API, bestaande auth, productie met echte gebruikers
- Acceptatie: uitnodiging per e-mail, rol toekennen, uitgenodigde kan inloggen, admin ziet status
Developer A (€120/u, 3 uur) en Developer B (€80/u, 6 uur) krijgen exact dezelfde ticket — met doel, context en acceptatiecriteria. Zie sterke tickets schrijven als referentie.
De rekening: lager uurtarief, hogere factuur
| Developer A | Developer B | |
|---|---|---|
| Uurtarief | €120 | €80 |
| Uren | 3 | 6 |
| Totaal | €360 | €480 |
| Verschil | — | +€120 duurder |
Als je hier stopt met vergelijken, lijkt B logisch: "meer uren = grondiger werk." Maar uren zeggen niets over kwaliteit. Soms zijn 6 uren nodig omdat iemand zoekt, trial-and-error doet, of scope niet begrijpt. Soms zijn 3 uren genoeg omdat iemand dit vaker heeft gedaan — en meteen de juiste keuzes maakt.
De echte benchmark begint na oplevering: volledigheid, veiligheid, doorbouwen. Daar loopt B vaak verder uit — terwijl A al goedkoper was.
1. Volledigheid
Developer A (3 uur, €360): feature werkt end-to-end — uitnodiging, token, registratie-flow, rol in database, admin-overzicht. Edge cases benoemd: verlopen link, dubbele uitnodiging, gebruiker bestaat al. Eén kleine follow-up ticket voor e-mail template styling (30 min later).
Developer B (6 uur, €480): happy path werkt in demo. Geen afhandeling "uitnodiging al verstuurd", geen check op bestaand account, admin ziet niet wie pending is. "Dat kan in een volgende sprint." Jij denkt: de opdracht was af — maar acceptatiecriteria waren niet gehaald.
Benchmark-vraag: zijn alle acceptatiecriteria gehaald zonder stilzwijgende "fase 2"?
Volledigheid is geen luxe. Onvolledige features worden support-tickets — extra uren, extra kosten, bovenop die €480.
2. Veiligheid
Developer A: uitnodigingstoken cryptografisch random, eenmalig, verloopt na 48 uur. Rate limit op endpoint. Geen gevoelige data in URL. Input gevalideerd server-side. Kort bericht in PR: wat is afgeschermd en waarom.
Developer B: token is userId + timestamp in base64 — voorspelbaar. Geen expiry. Endpoint open voor enumeration. "Werkt op mijn machine" — geen security-review.
Herstel van B kost al snel 4–8 uur extra (€320–€640 bij €80/u) — plus risico als het al live stond. Zie ook AI security; de principes gelden voor elke feature.
Benchmark-vraag: zou jij dit zonder schaamte live zetten voor betalende klanten?
3. Documentatie
Developer A: korte README-sectie — hoe flow werkt, welke env vars, hoe te testen lokaal. Ticket bijgewerkt met "done + hoe te verifiëren". Geen roman; wel genoeg dat een collega maandag kan overnemen.
Developer B: geen docs. "De code spreekt voor zich." Jij opent het project drie weken later — geen idee welke endpoint wat doet.
Documentatie is onderdeel van volledigheid — vooral als je met wisselende developers of een partner werkt. Bij Teamcoda hoort dat bij Coda-tickets: oplevering inclusief hoe te testen.
Benchmark-vraag: kan iemand anders dit onderhouden zonder mondelinge overdracht?
4. Architectuur
Developer A: uitnodiging-logica in een service-laag, niet in de route handler. Hergebruik bestaande mail-service. Duidelijke scheiding: domain / API / infra. Past in bestaande mapstructuur. Geen nieuwe dependency voor één regel code.
Developer B: alles in één controller van 400 regels. Copy-paste van Stack Overflow. Extra npm-package voor iets wat native kan. Volgende feature duurt langer omdat niemand de file durft aan te raken.
Architectuur bepaalt hoe snel je daarna doorbouwt. Lees technische schuld herkennen — B levert vaak onzichtbare schuld mee, bovenop die hogere factuur van €480.
Benchmark-vraag: maakt deze oplevering de codebase beter, neutraal, of erger?
5. Hoe erop verder bouwen
Stel: over twee maanden wil je rollen uitbreiden (admin, editor, viewer) en SSO toevoegen.
Na Developer A: rollen zitten al in het model; uitbreiden is een logische volgende ticket. SSO koppelt aan bestaande auth-laag. Inschatting: 1–2 dagen — realistisch.
Na Developer B: rollen hardcoded als string "admin". Auth verspreid over drie files. Inschatting: "eerst refactoren" — 1–2 weken voordat je überhaupt SSO kunt beginnen.
De €480 van B was dus geen "grondig" alternatief — het was een duurder startpunt. De echte kosten komen bij de volgende feature. Dat is waar feature-prijs versus uurtarief en total cost of ownership samenkomen.
Benchmark-vraag: versnelt dit de roadmap — of remt het alles af?
6. Meegedacht en feedback gegeven
Dit is waar senioriteit het vaakst zichtbaar wordt — niet in typen, maar in denken.
Developer A: vóór bouwen: "Jullie ticket vraagt e-mailuitnodiging — willen jullie ook bulk-invite later? Zo ja, dan modelleer ik het generiek." Tussendoor: "Jullie huidige auth ondersteunt geen magic links — ik stel voor X i.p.v. Y, anders security-risico." Na oplevering: "Getest op Safari — hier een kleine fix. Overweeg rate limit op productie — kan ik in 20 min meenemen."
Developer B: bouwt precies wat letterlijk in het ticket staat — ook als het ticket incompleet was. Geen vragen. Geen alternatieven. Geen waarschuwing. Jij bent de product owner én de security officer geworden zonder dat je het merkte.
Meedenken is geen scope creep. Het is voorkomen dat je over drie maanden alsnog betaalt voor wat je had moeten weten in uur één.
Benchmark-vraag: heeft deze developer jouw product slimmer gemaakt — of alleen code afgeleverd?
Scorekaart: zo vergelijk je op waarde
Geef per criterium 1–5 (1 = onacceptabel, 5 = productie-klaar). Gewicht naar jouw situatie — startup MVP vs. scale-up met compliance.
- Volledigheid — acceptatiecriteria gehaald?
- Veiligheid — live-ready zonder schaamte?
- Documentatie — overdraagbaar zonder call?
- Architectuur — codebase beter of erger?
- Doorbouwen — volgende feature sneller of trager?
- Meegedacht — risico's en keuzes expliciet gemaakt?
Voorbeeldscore (illustratief):
- Developer A: 5, 5, 4, 5, 5, 5 → 29/30 — factuur €360
- Developer B: 3, 2, 1, 2, 2, 1 → 11/30 — factuur €480
Goedkoper én beter op waarde. En dan rekenen we rework nog niet mee — die komt bij B bijna altijd bovenop.
Hidden costs bovenop die €480
Reken naast de factuur mee:
- Rework — security fix, refactor, bugs (2–20+ uren × €80 = €160–€1.600 extra)
- Jouw tijd — jij als tester, PM, security — uren die nergens op de factuur staan
- Vertraging — roadmap loopt maand achter; opportunity cost
- Moral hazard — bij uurtarief zonder cap heeft B soms perverse incentive om langer bezig te blijven (niet iedereen; wel een risico om te kennen)
Developer A's €120/u is hier de goedkopere én betere keuze: €360 upfront, minder rework, sneller doorbouwen. Vergelijk op totale waarde, niet op uurtarief alleen.
Wanneer 6 uur voor €80 wél de betere deal is
Eerlijk blijven: soms is de langzamere developer de juiste keuze — maar dan moet het kloppen.
- Junior met senior review — bewust goedkoper pad met spelregels
- Complex domein waar tijd nodig is voor begrip — 6 uren zijn dan investering, geen waste
- Documentatie en tests uitgebreid meegenomen — uren zitten in kwaliteit, niet in zoeken
- Vaste prijs afgesproken — €480 max, risico bij B
- Oplevering scoort hoog op alle zes criteria — dan is €480 fair
Benchmark gaat niet om "duurder uurtarief always wins." Het gaat om niet automatisch B kiezen omdat €80 < €120 — terwijl B je meer factureert en minder oplevert.
Praktisch: dezelfde opdracht, fair vergelijk
- Schrijf één ticket met duidelijke acceptatiecriteria
- Geef het aan beide (of twee kandidaten) — betaald, zelfde scope
- Reken totaalprijs: uren × tarief — niet alleen tarief
- Beoordeel op de zes criteria hierboven — niet op "wie was aardig"
- Plan een kort gesprek: "Waarom deze keuzes?" — luister naar trade-offs
- Kies op totale waarde — factuur + kwaliteit + doorbouwen
Meer stappen: developers benchmarken.
Hoe Teamcoda hiernaar kijkt
Wij zijn niet de goedkoopste per uur — en hoeven dat ook niet te zijn. We willen wel voorspelbaar zijn: volledige oplevering, veiligheid niet als afterthought, documentatie die past bij het werk, architectuur waar je op doorbouwt, en eerlijk feedback vóór je geld aan de verkeerde richting uitgeeft.
Snel klaar is geen truc — het is ervaring. Goedkoper totaal is geen discount — het is minder rework. Via Coda zie je wat we doen en waarom. Via technologisch partner bouwen we langdurig — waar die scorekaart elke sprint opnieuw bewijs levert.
Twijfel over code die je al hebt? Externe audit of Vibe Coding Schil — objectieve benchmark van waar je staat.
Wil je dezelfde opdracht eens door ons laten inschatten? Mail info@teamcoda.com — we reageren met scope, uren en aanpak, geen verkoopscript.
