Een freelancer inhuren

Je hoeft zelf niet te kunnen programmeren om een goede freelance ontwikkelaar te kiezen, iemand die als zelfstandige op opdracht software voor je bouwt. Veel van wat je wil weten, zou je ook bij een aannemer of een boekhouder nagaan: luistert die persoon, kan die tonen wat er eerder gemaakt is, en begrijp je wat er gezegd wordt?

Helsh-js is zelf een studio van één persoon, dus wat hieronder staat, kan je ook op mij toepassen.

Waar je begint

Schrijf eerst op wat je nodig hebt, ook al is het kort en onaf. In Een briefing schrijven lees je hoe, zonder technische kennis. Met zo’n tekst vertel je aan iedereen hetzelfde verhaal, en dat maakt de antwoorden makkelijker te vergelijken.

Vraag daarna rond bij andere ondernemers die al eens software lieten bouwen, en spreek met meer dan één persoon. Je leert al veel uit het verschil tussen twee gesprekken over hetzelfde probleem.

Vraagt die naar je probleem?

Let in het eerste gesprek op wie de vragen stelt, en waarover. Zelf begin ik met luisteren: wat heb je nodig, waarom heb je het nodig, hoe doe je het nu? Doe je het manueel of in Excel, en waarom wil je daarvan af? Een andere ontwikkelaar mag het anders aanpakken, maar moet genoeg over je werk weten om over techniek of prijs te kunnen praten.

Let ook op de woorden van je sector. Elk bedrijf heeft eigen termen, en een “order” kan bij jou iets anders betekenen dan bij je buurman. Iemand die dat navraagt, is bezig om jouw werk te begrijpen.

Het is ook een goed teken als iemand durft te zeggen dat je iets niet nodig hebt. Vraag gerust: “Wat zou jij weglaten?” Het antwoord toont hoe iemand meedenkt over wat in een eerste versie hoort.

Toont die werk?

Vraag naar dingen die je zelf kan openen: een website, een app in de appstore, een demo. Een werkende demo is meer waard dan een presentatie, want je kan erop drukken. Kijk of het vlot werkt op je telefoon en of je begrijpt wat je moet doen.

Vraag daarna wat die persoon precies deed. Is alles door die persoon gebouwd, of een deel binnen een groter team? Allebei is prima, zolang je weet waar je naar kijkt. Goede vervolgvragen zijn wat er moeilijk was en wat er veranderde nadat de eerste gebruikers het in handen kregen.

Een project uit jouw sector is mooi meegenomen. Meestal zegt het meer of iemand iets vergelijkbaars heeft gebouwd, zoals een app die zonder bereik moet werken of een koppeling met boekhoudsoftware.

Klantenwerk kan vertrouwelijk zijn. Dan kan iemand soms alleen het resultaat tonen en erover vertellen. Vraag ook of je een vroegere klant mag spreken. Ken je iemand met technische kennis, dan kan die voor jou ook eens naar een stuk code kijken.

Hoe communiceert die?

Aan het eerste contact kan je hier al veel aflezen. Legt iemand een vakterm uit zonder dat je erom moet vragen? Krijg je na een gesprek een duidelijk antwoord op papier, en begrijp je wat er nu zou gebeuren?

Vraag ook hoe je het werk zal zien groeien. Ik toon al vroeg werkende software, op een testadres dat je zelf kan openen. Een testadres is een aparte versie van je product die nog niet openbaar is. Bespreek ook hoe vaak jullie er samen naar kijken, en via welk kanaal je elkaar bereikt.

Vraag wie de code schrijft. Bij mij is de persoon aan de telefoon de persoon die de code schrijft. Een freelancer kan ook werk uitbesteden, dus vraag dat er meteen bij. Omdat het om één persoon gaat, mag je ook vragen wat er gebeurt tijdens een vakantie of bij ziekte. Een rustig, concreet antwoord is genoeg. Of één persoon wel de juiste keuze is, lees je in Freelancer, bureau of eigen team?

Van wie wordt de code?

Stel die vraag voor je begint, aan elke ontwikkelaar. Bij mij zijn de code en de data van de klant. Neem dat bij niemand als vanzelfsprekend aan: bij een freelancer kan het auteursrecht op de code bij de maker blijven, tenzij een contract iets anders zegt. Laat dat nakijken door een jurist, want de regels hangen af van je situatie.

Vraag ook op wiens naam de accounts komen, zoals je domeinnaam, je hosting, de plek waar de code staat en je appstore-accounts. Meer daarover lees je in Van wie zijn je code en je data?

Wat er na de lancering gebeurt

Software heeft na de lancering nog onderhoud nodig: foutjes, updates, nieuwe wensen. Vraag of de freelancer daarna beschikbaar blijft, en hoe dat werkt. Vraag ook wat er gebeurt als jullie stoppen. Zelf blijf ik erbij, of ik draag het netjes over.

Begin met iets kleins

Je hoeft niet meteen alles samen te bouwen. Start met een eerste stuk, zoals een plan op papier, een prototype of een klein deel van het product. Dan zie je hoe het samenwerken gaat, en je kan daarna nog altijd beslissen.

Vergelijk prijzen op wat erin zit. Twee offertes voor “een app” kunnen over heel iets anders gaan, en Wat maakt een app duur of goedkoop? helpt je om dat verschil te zien. Heb je iemand gevonden, neem dan deze vragen mee voor je tekent.