Inspiratie

Een eigen developer vs. samenwerken met een techpartner. De voor- en nadelen op een rij.

Leestijd 5 min

Door Maurits Dijkgraaf
  • Blog

Je bent ondernemer met een software-idee, of wellicht heb je al een softwareoplossing die goed loopt. Je wilt verder. Nú bouwen, of opschalen om je oplossing uit te bouwen. Daarbij sta je voor de keuze: neem je zelf één of meerdere developers (extra) aan, of kies je ervoor om de oplossing extern te laten bouwen? Of wellicht kies je voor een hybride vorm, waarbij externe specialisten jouw eigen team ondersteunen en aanvullen. In dit artikel zetten we de voor- én nadelen van deze opties op een rij. Wat kost een developer eigenlijk? Wat voor rollen heb je nodig? En wat doe je als jouw eigen ontwikkelaar plots opzegt?

Developer aan het werk

Wat kost een eigen developer?

Een belangrijk element voor jouw keuze is uiteraard het kostenplaatje. Daarom kijken we eerst naar wat een eigen developer eigenlijk kost. Dat start al bij de werving. Goede developers zijn lastig te vinden, waardoor er snel vijftien- tot twintigduizend euro in de werving gaat zitten.

Vervolgens betaal je een goed salaris, waarbij je de eerste één à twee maanden inwerktijd moet rekenen (ongeveer tienduizend euro). Daarnaast heeft een developer een pc van een paar duizend euro nodig, een ontwikkeling- en acceptatieomgeving en licenties voor diverse systemen, die helpen bij de bouw en security van jouw oplossing. Het eerste halfjaar kost zoiets al gauw zesduizend euro.

Eenmaal begonnen na de inwerktijd, duurt het zomaar nog eens tot drie maanden voordat de productie begint te lopen op het gewenste niveau en met de juiste kwaliteitsstandaarden. Reken daar zo’n vijfduizend euro voor.

Tel je dat allemaal bij elkaar op, dan kom je al snel op veertigduizend euro bruto uit voor een gemiddelde developer eer dat deze up-and-running is. Over het algemeen zijn developers wel trouw. Geef je aan hen de juiste uitdaging, dan zullen ze niet snel vertrekken.

Zet je dat totaalbedrag af tegen het inhuren van externe specialisten, dan kun je voor veertigduizend euro ongeveer 360 uur aan ontwikkeluren verwachten. Daarmee kan een klein team ongeveer drie weken lang werken en een klein prototype of app hebben staan.

PAQT - Software - Robert en Maurits

Eigen developer of externe specialisten

Wanneer kies je nu voor een eigen developer en wanneer voor samenwerken met externe specialisten? Een belangrijk uitgangspunt is het analyseren van je eigen organisatie en type product. Een enkele developer is prima in staat om een simpele oplossing zelfstandig op te zetten in bijvoorbeeld een startup. Zeker als deze daarbij gebruikmaakt van standaarden in code. Voor een beginnende, relatief eenvoudige app is dit daarom vaak een snelle en haalbare optie.

In de beginfase, wanneer jouw idee een concrete oplossing wordt, moet er veel uitgezocht worden. Daar gaan veel uren in zitten en commitment van jouw developer is daarom essentieel. Bij voorkeur is je developer daarom co-founder, omdat je dan het ondernemerschap en de verantwoordelijkheid kunt verwachten. Goede afspraken maken kan natuurlijk ook.

Full stack of specialist

De developer die álles kan, bestaat niet. Voor startende, eenvoudige applicaties kom je ver met één full stack developer, die van alles een beetje weet. Zodra je verder groeit, zal de algemene brede kennis van zo’n developer niet toereikend zijn en is er meer specialistische kennis nodig. Meestal is dit het punt wanneer jouw enkele oplossing overgaat naar een verzameling van oplossingen (een suite). Dan heb je al snel een volwaardig team nodig om de complexere techniek in te richten.

Zo’n team bestaat al gauw uit meerdere fulltime backend developers, een frontend developer en product owner. Parttime heb je dan ook nog een tester, designer, devops en een software architect nodig als je een complexere, schaalbare applicatie bouwt.

Een team is kwalitatief altijd beter dan een enkele developer. Teamleden kunnen code reviews doen, oftewel: elkaar controleren en versterken. Dat is al goed om te doen bij startende applicaties, maar wordt alleen maar belangrijker naarmate je verder groeit en je oplossing compleet wordt.

Welke team voor welk project Development team matrix

Maar welk team past nou het beste bij welke project? Op basis van de complexiteit en hoe experimenteel een oplossing is, kun je een inschatting maken welk team geschikt zou zijn.

Zo zie je dat bij een complex product met een hoge mate van onzekerheid, een multidisciplinair innovatieteam gepast is. Werk je echter aan een eenvoudig product dat weinig onzekerheid kent, dan voldoet misschien wel een enkele developer. Daar tussenin kan het zijn dat er meer ervaring gevraagd wordt in een team, of juist een developer met een bredere skill set nodig is.

Een techpartner

Groei je hard, of heb je niet de mogelijkheid te starten met eigen developers, dan is een techpartner het overwegen waard. Je kunt daarbij twee richtingen op: volledig aan de slag met externe specialisten, of deze combineren met eigen developers. Zo creëer je een hybride vorm van enkele eigen developers met een techpartner. Zij kunnen je team bijstaan en specifieke kennis aanvullen. In afgebakende sprints kan de oplossing snel uitgebouwd worden, zonder een compleet team op de payroll te hebben.

Verwacht je dat jouw oplossing snel complexere vormen aanneemt en is je organisatie qua omzet groot genoeg, dan is het wellicht handiger om een compleet eigen team van specialisten te overwegen. Je begint dan gelijk met een solide basis, je hebt de kennis volledig in huis en altijd een team beschikbaar om aan jouw oplossing te werken. Is jouw applicatie groot genoeg, dan zal dat geen probleem zijn. Maar besef dan wel dat je dan echt een softwarebedrijf moet willen worden. Is je organisatie voldoende IT-minded om daaraan te beginnen?

Afhankelijk dus van het type organisatie, blijft het ook als groot bedrijf interessant om met een techpartner te werken. Eventueel hybride, waarbij de techpartner de regie behoudt maar je ook je eigen ontwikkelaars hebt.

Verder kijken dan enkel de kosten

Het outsourcen van developers kost gemiddeld zo’n 30% meer dan het inhuren van je eigen team. Daar tegenover staan wel een groot aantal voordelen. Het biedt flexibiliteit waarmee je, als het een keer moet, snel kan opschalen. Is er een periode minder werk, schaal je weer af. Wil je een keer twee keer zo hard gaan? Dan kan een externe partner dat sneller regelen, dan zelf extra capaciteit inhuren. Uiteindelijk kun je met een techpartner vaker veel sneller de markt op.

Jelmer en Arlon - development

Een eigen team betekent dat je alle kennis in huis hebt en dat als alles goed gaat, je veel minder afhankelijk bent van externen. Het lijkt dus op het oog al gauw goedkoper. Maar het is daarnaast veel lastiger om voor elkaar te krijgen. Lukt het je de kennis in huis te halen in deze krappe arbeidsmarkt en het team continu aan het werk te houden?

Een eigen team brengt ook risico’s met zich mee. Werk je aan een experimenteel product, dan loop je het risico verkeerd te bouwen. Werk dat later wellicht veel tijd kost om weer te corrigeren. Bouw je een complex product, bestaat de kans dat je team zich vertilt en een te lage kwaliteit bouwt. Met tot gevolg dat je later in de problemen kan komen op het gebied van o.a. security of toekomstbestendigheid.

Daarbovenop moet je rekening houden dat je team compleet moet blijven. Vertrekt één van de eerdergenoemde rollen, dan moet je opnieuw werven en inwerken, waarbij tijd en kennis verloren gaat.

Uiteraard geldt het verlies van kennis ook voor ingehuurde teams bij een techpartner. Wanneer je echter kiest voor een partner met meerdere teams, kan hier vaak wel sneller worden geschakeld door bepaalde expertise vanuit andere ontwikkelteams te halen. Allemaal risico’s die je met het kiezen voor een externe partner min of meer afkoopt. Vertrouwen in je externe partij is daarentegen ook weer ontzettend belangrijk, aangezien je er wel afhankelijk van blijft.

Altijd up to date

Een ander belangrijk element om in je overweging mee te nemen bij jouw keuze voor aannemen of samenwerken, is het up-to-date houden van kennis, hardware en systemen. Techniek ontwikkelt zich snel, dus scholing van teams is essentieel om niet achter te lopen. Heb je een eigen team, dan moet je hen de ruimte bieden om bij te blijven en kennis verder te ontwikkelen. Bij PAQT hebben we hiervoor maandelijks de imPAQT day, waarbij developers zich vol op één thema kunnen storten.

Naast kennis, vragen ook de hardware en software continu updates. Je developmentteam zal daarom een deel van de tijd bezig zijn met het onderhoud en updates van randvoorwaardelijke systemen, servers en testomgevingen, om zaken als security en privacy te kunnen waarborgen. In de planning van werkzaamheden moet je daarom rekening houden dat je team nooit honderd procent aan het ontwikkelen is. Allemaal factoren die je in ogenschouw moet nemen om te bepalen of het waard is die 30% te besparen.

Contact met SaaS specialist Maurits

De beste keuze

Alles afwegende, is er geen eenduidig antwoord te geven op de vraag of je beter zelf een developer kan aannemen, of een team kan inhuren. Het hangt af van jouw applicatie, je omzet en jouw ambities om je oplossing te laten groeien.

Hoe complexer het wordt, hoe meer risico erbij komt kijken, waarmee het ook weer interessanter wordt om met een partner te werken. Heb je veel kennis van zaken, dan kun je ook zelf aan de slag. Bij een product dat weinig complexiteit en onzekerheid kent, is een toegewijde co-founder die non-stop aan de slag gaat als developer ontzettend waardevol. Komt er meer complexiteit bij kijken dan wordt het lastiger een eenvoudige keuze maken tussen aannemen of inhuren.

PAQT werkt als techpartner samen met diverse ondernemers en developers. Benieuwd of samenwerken iets voor jou is?

Bel Maurits voor een vrijblijvende kennismaking en ontdek zelf de mogelijkheden.

 

Neem contact met mij op

Laat je gegevens achter, dan nemen ik zo snel mogelijk contact met je op. Liever even bellen? Geen probleem, bel me direct via 06 – 430 91 030

Maurits Dijkgraaf

Alle artikelen