Voor je een developer aanneemt: lees dit eerst

Een developer aannemen voelt als vooruitgang. Iemand die fulltime aan jouw product werkt, sneller bouwt en de zaak in beweging brengt. Voor sommige founders is dat ook precies wat er nodig is.

Voor veel founders is het te vroeg.

Een developer lost geen onduidelijkheid op. Een developer voert uit wat al duidelijk is. Als de richting nog wankel is, bouwt iemand die je betaalt om snelheid te leveren, ook snel in de verkeerde kant op. Met iedere week aan code wordt het duurder om die kant weer recht te trekken.

Dit artikel beschrijft wat je beter eerst beantwoordt voor je iemand inhuurt. Niet om hires uit te stellen, maar om ze met meer zekerheid te kunnen doen.

Wanneer je wél een developer nodig hebt

Een developer betaalt zichzelf het snelst terug als drie dingen al kloppen: het probleem is concreet, de eerste klant ligt vast en de scope is klein genoeg om er binnen weken iets bruikbaars uit te halen.

In dat geval is de hire vooral uitvoering. Je kunt iemand uitleggen wat er moet komen, waarom dat belangrijk is en aan welke voorwaarden het moet voldoen. Een goede developer kan dan binnen een week starten en heeft genoeg context om zelf afwegingen te maken op dagelijkse vragen.

Iedere keer dat je dat niet kunt doen, is het probleem niet de hire. Het probleem zit boven de hire.

Wanneer je eerst scope nodig hebt

Veel founders nemen iemand aan met de gedachte: zodra die start, gaan we de scope samen aanscherpen. Dat klinkt logisch en is meestal duur.

Een developer wordt betaald om te bouwen. Die zal scope-discussies aangaan, maar staat onder druk om ergens aan te beginnen. Hoe langer de discussie duurt, hoe meer iemand het gevoel krijgt zijn loon niet te verdienen. Dus wordt er gekozen voor het deel waar wel duidelijkheid over is, meestal het minst belangrijke deel.

Beter is om de scope helder te krijgen voor er iemand staat. Een halve dag werk aan beslissingen is goedkoper dan een maand waarin een developer wacht op richting.

Het verschil tussen junior en senior is geen wens, maar een context

Founders denken vaak in budget: een senior is duur, dus we starten met een junior. Met goede begeleiding wordt het vanzelf een senior.

Dat klopt in een team van vijf ervaren developers. Niet in een team van één.

Een junior werkt met heldere taken en een ervaren reviewer naast zich. Geen van beide is er in een vroege startup. Een junior in zo’n omgeving doet wat die kan, maar mist het overzicht dat een vroeg product juist nodig heeft. De founder wordt vervolgens onbedoeld de reviewer, terwijl jij geen tijd hebt om elke pull request te beoordelen.

Een senior kost meer per maand. Niet per beslissing. Een senior stelt vragen die voorkomen dat je verkeerd begint. Die vragen besparen vaak meer dan zijn salaris.

Als je geen senior kunt betalen, is dat een signaal. Niet om dan maar een junior te nemen, maar om eerst je scope kleiner te maken zodat je iemand voor weken in plaats van maanden nodig hebt.

Waarom een onduidelijke opdracht duur wordt

Code is goedkoop om te schrijven. Code in productie is duur om te onderhouden. Iedere regel die niet gebruikt wordt, kost je later tijd. Iedere keuze die niet bij de business past, moet ooit terug.

Een onduidelijke opdracht produceert vooral code die later weg moet. Niet omdat de developer slecht is, maar omdat de instructies niet helder waren.

Je herkent het patroon hieraan: gesprekken over “we kunnen dit later altijd veranderen”. Dat klopt technisch, maar elke verandering kost geld en motivatie. Hoe verder je doorbouwt op een verkeerde basis, hoe minder je geneigd bent terug te gaan.

Vragen die je vooraf moet beantwoorden

Voor je iemand inhuurt, dwing jezelf deze vragen op papier te beantwoorden:

• Wie is de eerste klant en wat doet die nu zonder ons product?
• Welke aanname is het meest fragiel, wat moet als eerste waar blijken?
• Wat is de kleinste versie die een klant kan gebruiken?
• Wat hoort expliciet niet in de eerste versie?
• Wie is verantwoordelijk voor de productkeuzes, jij of de developer?
• Wat doe je over drie maanden als de hire niet werkt?

Vage antwoorden op deze vragen zijn geen reden om geen developer aan te nemen. Ze zijn een reden om eerst aan de antwoorden te werken.

Het is geen toeval dat veel van deze vragen ook terugkomen bij het scherper krijgen van een MVP-scope. De hire-vraag en de scope-vraag zijn dezelfde vraag in een andere vorm.

Waarom een founder eerst de beslissing moet aanscherpen

Het werk vóór de hire is meestal niet techniek. Het is kiezen wat er níet wordt gebouwd. Wat er níet betaald wordt. Wie de eerste klant níet is. Welke feature níet in v1 hoort.

Die “niet”-beslissingen zijn de moeilijkste. Ze voelen alsof je je product verkleint. In werkelijkheid maak je het product juist scherper.

Een ervaren blik kan helpen die afwegingen te maken. Niet om voor je te beslissen, maar om patroonherkenning aan te leveren: vergelijkbare keuzes die andere founders maakten en wat daarvan terugkwam.

Een uur sparren over de beslissing voorkomt vaak maanden waarin een developer iets bouwt wat niemand vraagt.

---

Sta je voor deze beslissing?

Stuur me kort de context of plan een gratis gesprek. Dan kijken we samen wat de meest verstandige volgende stap is voor je tijd, geld of focus vastlegt.

Plan een gratis gesprek → · Mail direct: hello@yourstartup.expert