20 Developers, een uurtarief en geen idee wat het project echt opleverde

"Ik kende het uurtarief van elke developer. Ik kende het contracttarief van de klant. Ik trok het ene van het andere af en dacht dat ik de marge kende. Toen bouwde ik een P&L per project en besefte ik dat ik vier jaar lang een bedrijf had gerund op basis van een fictie."

De oprichtster van een IT-outstaffbedrijf — 20 developers, ₴36 mln omzet per jaar, zeven actieve klanten — vertelde over de oefening die veranderde hoe ze werk prijsde en aannam.

Vier jaar lang runde ze het bedrijf op wat iedereen in de branche gebruikt: rekenen met het uurtarief. Elke developer had een kostprijs (gemiddeld ₴550/uur). Elke klant had een contracttarief (gemiddeld ₴950/uur over alle klanten). Simpel aftrekken gaf ₴400/uur brutomarge per developer, ~42% marge. Doorgetrokken over het hele team: comfortabel, winstgevend, groeiend.

Toen deed ze de oefening. Eén project erbij pakken. Niet het bedrag "we hebben de klant ₴X per uur gefactureerd". De echte project-P&L. Klantomzet voor die maand. Alle kosten die direct aan dat project toe te rekenen zijn. Alle kosten die indirect toe te rekenen zijn. Wat er overblijft.

Projectmarge bij haar grootste klant, over de voorgaande 12 maanden: 14%. Niet 42%.

Achtentwintig punten marge waren verdwenen in een reeks kosten waar het uurtarief-rekenwerk niet aan raakte.

Wat het uurtarief-rekenwerk eigenlijk verbergt

Het uurtarief gaat ervan uit dat een developer 100% van de tijd op het project is ingezet, gedurende die tijd 100% productief is, en dat het project alleen hun arbeid verbruikt. Niets daarvan klopt voor een echt dienstverlenend bedrijf. Bench en afbouwtijd (−5 punten). Als een project eindigt of een klant pauzeert, zit de developer zonder werk maar wordt wel doorbetaald. Gemiddeld twee weken per jaar, per developer. Niet factureerbaar. Gaat van de marge af.

Vakantiedagen en ziekteverzuim (−4 punten). Developers in loondienst krijgen betaald verlof en ziektedagen. Het contracttarief wordt alleen gefactureerd als ze werken. Het gat is onzichtbaar tot je het optelt.

Interne meetings, proces, sollicitatiegesprekken (−6 punten). Standups, retro's, planning, kandidaten interviewen, interne afstemming. Allemaal betaald, niets factureerbaar. Gemiddeld 4–6 uur per developer per week.

Tools en licenties (−2 punten). IDE-licenties, cloudinfrastructuur voor interne omgevingen, projectmanagementtools, monitoring, communicatieplatforms. Per stuk klein; telt op.

Recruitment- en managementoverhead (−7 punten). HR, delivery managers, projectmanagers, de eigen tijd van de oprichtster. Iedereen wordt betaald. Bijna nooit factureerbaar. Dit was het grootste lek op zich.

Korting en onbetaalde overuren (−4 punten). Klant onderhandelde bij verlenging over het tarief, kreeg 8% korting. Spoedwerk in het weekend niet altijd geregistreerd. Overschrijding op vastgeprijsde onderdelen geabsorbeerd.

Achtentwintig punten, zes categorieën, geen daarvan in het uurtarief-rekenwerk.

De heropbouw — het projectresultatenrekening-framework

De oprichtster bouwde haar P&L per project in een weekend. Het werd het belangrijkste document in haar bedrijf. Het framework is toepasbaar op elk dienstverlenend bedrijf. Eén — Projectomzet. Maandelijks gefactureerde uren × klant-contracttarief. Niet toegezegde verkoop; daadwerkelijk gefactureerd.

Twee — Directe developerkosten, volledig belast. Salaris + belastingen + secundaire arbeidsvoorwaarden + afschrijving apparatuur + betaald verlof, gedeeld door bruikbare uren (niet kalenderuren). Als een developer 65% van de tijd factureerbaar is, is de volledig belaste uurkostprijs salaris/(uren × 0,65).

Drie — Toegerekende project-, delivery- en recruitmentkosten. Ruwe verdeling naar projectgrootte of naar omzet. Hoeft niet perfect te zijn. Moet wel consistent zijn.

Vier — Tools en licenties toe te rekenen aan het project.

Vijf — Benchtoerekening. Totale benchkosten voor het jaar, verdeeld over actieve projecten.

Zes — Toerekening interne meetings en proces. Percentage betaalde uren dat naar niet-projectwerk gaat × toegerekende kosten.

Resultaat — Echte projectmarge. Bij haar grootste klant: 14%. Bij twee kleinere klanten: 21% en 8%. Bij één klant die ze dacht dat haar beste was: 3%.

Wat ze met de waarheid deed

Met de klant op 3% werd een gesprek over tariefverhoging gevoerd. Dat verliep goed; marge ging naar 12%. De klant op 8% had oplosbare problemen met scopediscipline (te veel service); marge ging naar 15%. Recruitmentoverhead werd heronderhandeld naar een vaste maandelijkse retainer in plaats van kosten per aanwerving. Interne meetings werden doorgelicht — drie wekelijks terugkerende meetings werden geschrapt. De bezettingsgraad van twee senior developers ging van 58% naar 72% door ze weg te halen bij benchzwaar intern werk en op klantwerk te zetten. De totale bedrijfsmarge ging van schijnbaar 42% (fictief) naar echt 19% (voor de heropbouw) naar echt 27% (zes maanden later). Belangrijker dan het cijfer: ze wist nu welke klant echt winstgevend was, welke de bench subsidieerde en welke haar stilletjes geld kostte.

Het framework — wat je moet bijhouden

Zes cijfers, maandelijks, per project:

• Echte factureerbare uren (niet toegezegde uren; werkelijk)
• Volledig belaste developerkosten per project
• Toegerekende managementoverhead (PM/DM/recruiter/oprichterstijd als % van de maand)
• Benchtoerekening (benchkosten van deze maand × omzetaandeel van het project)
• Echte projectmarge (omzet − al het bovenstaande)
• Bezettingsgraad per developer, apart bijgehouden van marge

Zes cijfers, één dashboard, maandelijkse review met de delivery lead. Twee uur per maand, houdt de fictie buiten de deur.

📌 Wil je weten of je projecten écht zo winstgevend zijn als je uurtarief-rekenwerk suggereert? Stuur ons drie maanden facturatiedata en een kostenoverzicht van het team — we bouwen de echte-marge-waterval per project en lopen die in 15 minuten met je door. [Vraag je gratis Finmap-diagnose aan →]