Voor een idee dat nog niet getoetst is, werkt een freelancer of een gespecialiseerde prototype-partij vaak sneller en voordeliger dan een bureau. Zodra je idee bewezen is en je verder wilt bouwen, telt capaciteit en continuïteit zwaarder, en past een bureau meestal beter. In alle gevallen let je op dezelfde punten: krijg je de code echt, is er aantoonbare ervaring met vergelijkbaar werk, en wat gebeurt er na oplevering.
Voor zo goed als elk software-idee kun je uit drie soorten partijen kiezen, en elk daarvan is sterk in iets anders.
Een freelancer is meestal de goedkoopste en meest flexibele optie. Je werkt rechtstreeks met wie het werk doet, de communicatielijnen zijn kort en er is weinig overhead. Het risico is dat je afhankelijk bent van één persoon: bij ziekte, een ander project of iemand die er simpelweg mee stopt, ligt jouw idee stil. Voor een kleine, afgebakende klus is dat te overzien, voor iets dat je langere tijd wilt doorontwikkelen is het een reëel risico.
Een bureau heeft doorgaans meer capaciteit: valt iemand uit, dan kan een collega het overnemen. Er is meestal een vast proces voor planning, testen en oplevering, en meer continuïteit voor de lange termijn. Daar staat tegenover dat de doorlooptijd en overhead vaak groter zijn dan bij een freelancer, en dat jouw project tussen andere klanten soms wat minder prioriteit krijgt.
Een prototype-partij is gespecialiseerd in één ding: van een idee snel naar een tastbare, klikbare eerste versie. Dat is geen vervanging voor de partij die later de volledige, schaalbare versie bouwt, maar wel een manier om eerst goedkoop te toetsen of je idee werkt. Handig als je nog niet precies weet wat je wilt laten bouwen, of eerst zeker wilt weten dat het de moeite waard is om MVP-software te laten maken.
Welke van de drie het beste past, hangt vooral af van waar je in het proces zit. Twijfel je nog of je een technische partij nodig hebt of het zelf kunt regelen, lees dan ook of je een technische medeoprichter nodig hebt. Is je idee nog niet getoetst, begin dan klein. Is het idee al bewezen en wil je bouwen of opschalen, dan wegen capaciteit en continuïteit zwaarder mee.
Los van welk type partij je kiest, zijn er een paar dingen die je bij iedereen checkt.
Het eerste punt is eigenaarschap van de code. Vraag expliciet of je de broncode krijgt, en waar die komt te staan: in een eigen repository van jou, of alleen bij de partij die het gebouwd heeft. Sommige partijen bouwen op een eigen platform of onder een licentie die je niet volledig meekrijgt, waardoor je vast kunt komen te zitten als de samenwerking stopt. Leg dit vooraf vast, niet achteraf.
Vraag daarna om aantoonbare ervaring met vergelijkbaar werk, niet alleen een portfolio met logo's. Iemand die vooral marketingwebsites heeft gebouwd, is niet automatisch de juiste partij voor een app met gebruikersaccounts en betalingen. Vraag door: wie deed het werk precies, wat was de rol van de partij, en kun je een eerdere opdrachtgever spreken?
Laat je ook uitleggen hoe ze van idee naar oplevering komen. Een partij die het proces kent, legt in een paar zinnen uit hoe een idee een plan wordt, wat de tussenstappen zijn en hoe je onderweg feedback geeft. Hoe scherper jij je eigen idee kunt overbrengen, hoe makkelijker dat gesprek gaat: lees ook hoe je je idee goed uitlegt aan een developer en wat je voordat je een bouwpartij benadert op orde kunt hebben.
Een oplevering is niet het eindpunt, ook al voelt het soms wel zo.
Vraag vooraf wie er verantwoordelijk is zodra de app live staat: wie lost een bug op, wie past iets aan als je iets wilt wijzigen, en tegen welke voorwaarden. Sommige partijen bouwen en zijn daarna moeilijk bereikbaar, waardoor je met een werkend product zit dat niemand meer aanraakt. Andere bieden een doorlopende afspraak voor beheer en verdere ontwikkeling.
Vraag ook hoe overdraagbaar het werk is. Als je op een gegeven moment met een andere partij verder wilt, kan een volgende ontwikkelaar dan uit de voeten met de code, of is die zo specifiek geschreven dat alleen de oorspronkelijke bouwer er iets mee kan? Dat is meteen een tweede reden om vroeg naar eigenaarschap van de code te vragen.
De meeste problemen zijn vooraf te zien, als je weet waar je op moet letten.
Een handvat om het gesprek met een kandidaat-partij te structureren.
Is je idee nog niet getoetst, of weet je al zeker dat je wilt bouwen en uitbreiden? Voor het eerste past een prototype-partij of freelancer vaak beter, voor het tweede weegt capaciteit en continuïteit van een bureau zwaarder.
Leg voor je tekent vast dat je de broncode krijgt en waar die komt te staan.
Laat een paar eerdere projecten zien die op jouw type product lijken, en vraag of je een eerdere opdrachtgever kunt spreken.
Vraag hoe ze van jouw idee naar een concreet plan komen, en welke tussenstappen je onderweg te zien krijgt.
Check wie verantwoordelijk is zodra het live staat, en hoe overdraagbaar de code is als je ooit wilt wisselen van partij.
Een freelancer heeft doorgaans minder overhead dan een bureau, wat de kosten vaak lager houdt. Daar staat tegenover dat je afhankelijk bent van één persoon, terwijl bij een bureau meerdere mensen het werk kunnen overnemen als iemand uitvalt.
Dat hangt van je fase af. Is je idee nog niet getoetst, dan is eerst een klein, tastbaar prototype vaak slimmer dan meteen de volledige, schaalbare versie te laten bouwen. Is het idee al bewezen, dan telt de capaciteit van een bureau zwaarder mee.
Niet automatisch. Leg dit vooraf vast in de overeenkomst, inclusief waar de code komt te staan. Twijfel je over de juiste formulering, laat de voorwaarden dan even checken.
Vraag naar concrete, vergelijkbare voorbeelden in plaats van een algemeen portfolio, en vraag of je een eerdere opdrachtgever kunt spreken over hoe het traject verliep.
Vraag dit voordat je begint. Leg vast wie verantwoordelijk is voor beheer en kleine aanpassingen na livegang, en wat er gebeurt als je grotere doorontwikkeling wilt.
Ja, dat is een gangbare route. Je toetst je idee eerst met een klein, werkend prototype, en gebruikt de uitkomst als startpunt voor het gesprek met een bureau dat de volledige, schaalbare versie bouwt.
In één werkdag bouwen we een klikbaar prototype van je kernflow, zodat je zelf al weet waar je precies naar zoekt voordat je een freelancer of bureau inschakelt.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.