Waarom een developer aannemen geen productprobleem oplost

Een founder belt me met een herkenbaar verhaal. Ze hebben twee maanden geleden een developer aangenomen. De developer is goed, werkt hard en levert wat er gevraagd wordt. Toch beweegt het product niet vooruit. Klanten reageren wisselvallig, de roadmap wordt elke twee weken aangepast, en de founder begint te twijfelen of de hire wel klopt.

De hire klopt meestal wel. Het probleem zit niet bij de developer. Het probleem zit bij de beslissing waarop die developer wordt ingezet.

Een developer aannemen lost geen productprobleem op. Een developer voert uit. Als de productrichting nog niet helder is, gaat de uitvoering sneller, maar de richting blijft fout.

Het verschil tussen een bouwprobleem en een beslisprobleem

Veel founders behandelen “we hebben een developer nodig” als de oplossing voor een ander, eerder probleem dat ze niet helemaal scherp hebben. Dat eerdere probleem is meestal een beslisprobleem.

Een bouwprobleem klinkt zo: “We weten wat we willen bouwen en we hebben iemand nodig die het bouwt.” Dat is een hire-vraag.

Een beslisprobleem klinkt zo: “We weten dat we iets moeten bouwen maar zijn niet helemaal zeker over wat, voor wie, en in welke volgorde.” Dat is geen hire-vraag. Dat is een richting-vraag.

De grootste fout is om een beslisprobleem op te lossen met een bouwoplossing. Dan koop je snelheid op iets waarvan nog niet vaststaat dat het de juiste richting is. Hoe sneller je gaat, hoe verder je in de verkeerde kant op komt.

Waarom developers duidelijke keuzes nodig hebben

Goede developers stellen vragen. Welke gebruiker moet dit gebruiken? Wat is hun probleem? Welke data is beschikbaar? Wat hoort hier wel en niet bij?

Als jij daar geen antwoorden op hebt, kiest de developer zelf. Niet uit slechte wil, uit noodzaak. Er moet ergens gebouwd worden, dus hij maakt aannames. Soms goede, soms niet, en je merkt het pas weken later als de feature anders blijkt dan je verwachtte.

Een developer is geen productmanager. Vragen die jij niet beantwoordt, krijgen technische antwoorden in plaats van klant-antwoorden. Dat is duurder om terug te draaien dan de tijd die je had moeten besteden om het zelf scherp te krijgen.

Wanneer een developer juist vertraagt

In een vroege fase kan een developer een team vertragen in plaats van versnellen. Niet omdat de developer langzaam is, maar omdat de founder nu een aanvullende rol heeft: productkeuzes maken, prioriteren, vragen beantwoorden, code reviewen. Allemaal werk dat van het echte founder-werk afgaat.

Founders met één developer worden onbedoeld productmanager, support-medewerker én projectleider. Het werk waar ze juist tijd voor wilden, klanten spreken, beslissingen nemen, het bedrijf vormgeven, gaat achteruit. De developer wordt productiever; de founder minder.

Bij een team van drie of meer developers met een eigen lead is dat anders. In een team van één is een te vroege hire vaak het moment waarop de founder zelf verdwijnt uit de delen waar zij het meest waard zijn.

Waarom founders vaak te vroeg inhuren

Drie patronen die ik herhaaldelijk zie:

Het voelt productief. Een developer aannemen geeft het gevoel dat het bedrijf groeit en dat er beweging is. Dat gevoel is op zich waardevol, voor de founder. Niet automatisch voor het product.

Het is concreet. Bouwen aan beslissingen is moeilijk en onzeker. Iemand aannemen is concreet, je kunt een vacature opstellen, gesprekken voeren, een contract tekenen. Het is verleidelijk om concrete dingen te kiezen boven moeilijke dingen.

Er is geld of vertrouwen om uit te geven. Net binnengehaalde investering of net bevestigde lead-pijplijn maakt dat een hire betaalbaar voelt. Dat de hire de juiste beslissing is, daar wordt niet apart over nagedacht.

Geen van deze patronen is verkeerd. Ze maken alleen dat de hire-vraag wordt beantwoord voor de richting-vraag is gesteld.

Wat eerst helder moet zijn

Voor je een developer aanneemt, dwing jezelf om deze punten op papier scherp te krijgen:

• Eerste klant. Wie is de allereerste klant die ons product gaat gebruiken? Niet “small businesses”. Eén persoon, één bedrijf, één situatie.
• Eerste taak. Welke ene taak gaat die klant uitvoeren met het product? Niet “managementoverzicht”. Eén concrete actie.
• Wat er níet in zit. Welke features horen expliciet niet in de eerste versie? Schrijf het op, anders glijdt scope vanzelf weer omhoog.
• Beslissingsroute na de eerste klanten. Wat doen we als de eerste vijf klanten enthousiast zijn? Wat als ze niet enthousiast zijn? Wat zien we waaruit?

Vage antwoorden zijn geen reden om geen developer aan te nemen. Ze zijn een reden om eerst aan de antwoorden te werken. Zie ook de vragen die je vooraf moet beantwoorden.

Wat een ervaren blik kan voorkomen

Ervaren patroonherkenning kan een founder twee dingen geven die intern moeilijk te organiseren zijn: een onafhankelijke stem die “nog niet” zegt, en concrete voorbeelden van vergelijkbare keuzes en hoe die uitpakten.

Een founder die voor het eerst een developer overweegt, vergelijkt zichzelf met andere founders die het hebben gedaan. Die andere founders praten meestal over wat werkte, niet over wat in een verkeerd ritme gebeurde. Een gesprek met iemand die honderden van deze keuzes heeft gezien, brengt de minder zichtbare patronen ook in beeld.

Soms is het advies “neem nu aan”. Soms is het “wacht zes weken en werk eerst aan deze drie dingen”. Soms is het “deze hire is goed, maar pas hem aan op deze manier”. Wat het advies precies wordt, kan ik vooraf niet zeggen. Wat ik wél weet: het is altijd goedkoper dan een hire die vier maanden later niet de gewenste richting bracht.

---

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