Van goed idee naar goed werkende software: acht tips voor een vlekkenloos ontwikkeltraject

1. Een goed idee brengt geld met zich mee

‘Er melden zich bij ons heel veel start-ups en in de meeste gevallen hebben ze ook echt een goed idee. Maar niet in alle gevallen hebben ze ook geld. Ik geloof erin dat een goed idee geld moet kunnen ophalen, dus dan verwijzen we ze eerst naar investeringspartijen als NOM of we brengen ze in contact met Flinc zodat ze begeleid kunnen worden naar een passende financiering. We zien ze niet altijd weer terug daarna’, legt Sportel uit. ‘Een app of software laten ontwikkelen kost geld, maar ook het vermarkten is een kostbare aangelegenheid die vaak wordt onderschat. Ik raad altijd aan om minstens het dubbele van het ontwikkelbudget te reserveren voor marketing en sales.’

2. Denk groot, begin klein

‘We zien te vaak gebeuren dat er enorm ingewikkelde applicaties worden gebouwd in een complex ontwikkeltraject en dat die vervolgens aansluiting missen met de klantbehoeften. Daarom adviseren we altijd om klein te beginnen met een zogenaamd minimal viable product, een MVP. Zeg maar: de essentie van de applicatie. Dit is overzichtelijk qua budget én geeft de mogelijkheid om te testen met de eindgebruiker. Dat is een ontzettend belangrijke stap die nog vaak wordt overgeslagen. Enthousiaste ondernemers zijn ambitieus en willen veel tegelijk, maar het is echt de kunst om eerst het minimale in de lucht te krijgen en daarna uit te bouwen. Denk groot, begin klein.’

3. Betaal voor onderzoek, dat betaalt zich terug

‘Bij ons start er geen traject zonder een betaald vooronderzoek. Hierin maken we, zonder een regel code te schrijven, inzichtelijk hoe de applicatie gaat werken, welke schermen er moeten komen, welke interactie waar van belang is en brengen we in kaart welke technische uitdagingen we zien. Deze schets vormt de basis voor de rest van het ontwikkeltraject en bespaart uiteindelijk geld, tijd en verrassingen. We geven ook pas een definitieve offerte af als we dit vooronderzoek hebben afgerond, omdat we de tijdsinvestering dan beter kunnen inschatten. Dat is helder en transparant voor ons, maar ook voor de opdrachtgever. Ik zou deze stap dus zeker niet overslaan. Sterker nog: zo’n schets geeft je als opdrachtgever de mogelijkheid direct met eindgebruikers in gesprek te gaan. Hoe eerder je dat doet, hoe beter het product uiteindelijk wordt. En eventuele aanpassingen van de initiële schets zijn een stuk makkelijker door te voeren dan als er al code ligt.’

4. Voorkom vertraging door mandaat

‘Zorg ervoor dat er snel geschakeld kan worden door één persoon contact te laten onderhouden met het bureau. Deze persoon moet dan wel mandaat hebben. Te lange perioden van stilstand, teveel kapiteins op één schip en teveel overlegmomenten zijn heel vaak oorzaak van kostbare vertraging. Een project slaat dan dood en dat is zonde.’

5. Borg technische kennis

‘Een applicatie laten ontwikkelen zonder technische kennis is lastig. En de meeste ondernemers hebben hier logischerwijs weinig zicht op. Daarom is het slim iemand aan te trekken die wel van de hoed en de rand weet en mee kan kijken tijdens het traject. Dat beschermt je tegen de cowboys die helaas nog steeds rondlopen en nog wel eens gebruik maken van een gebrek aan kennis. Maar ook voor het bureau is het fijn om te kunnen schakelen met iemand die dezelfde taal spreekt. Maak hier dus budget voor vrij. Op het moment dat de onderneming groeit raad ik altijd aan een CTO aan te nemen. Als techniek een bedrijfskritische factor is, dan verdient dit absoluut onverdeelde en deskundige aandacht.’

6. Omarm het bureau dat kritische vragen stelt

‘Je hebt een fantastisch idee, kreeg het vertrouwen van een investeerder, de juiste mensen zitten op de juiste plek en bent helemaal klaar voor de start. Alleen nog even een bureau kiezen die de applicatie gaat bouwen. Dan is het belangrijk om scherp te zijn, want deze keuze kan het succes bepalen. Vraag eerst in je netwerk of het netwerk van bijvoorbeeld je investeerder naar referenties en ervaringen. Ga vervolgens altijd in gesprek met minstens twee partijen. Het verbaast mij nog steeds hoe werkwijzen, maar ook offertes zo ontzettend kunnen verschillen. Maar mijn belangrijkste tip is om kritische vragen van een bureau te omarmen. Dit is namelijk het belangrijkste signaal dat je te maken hebt met een professionele partner. Er zijn genoeg partijen die gewoon alles maar bouwen als er genoeg geld wordt overgemaakt. Wat je, vind ik, moet willen is een echt partnerschap: kies voor mensen die gezond kritisch zijn op welke opdrachten ze aannemen en alleen bouwen waar ze echt in geloven. Uiteindelijk maakt een samenwerking met die uitgangspunten echt het verschil voor het eindproduct.’

7. Bureau versus ontwikkelen in huis

‘Software hoeft natuurlijk niet per se door een bureau ontwikkeld te worden, dat kan ook prima ‘in-house’. Neem bij die overweging wel een aantal belangrijke zaken mee. Er is bijvoorbeeld geen controle op de ontwikkeling. Helemaal als je zelf niet technisch onderlegd bent, is het onmogelijk om te beoordelen of de code goed werkt. Laat staan of de code goed overgedragen kan worden, mocht de programmeur uitvallen. Het hangt in deze constructie echt allemaal van een persoon af. Iemand kan ziek worden of besluiten iets anders te gaan doen. Is de code dan goed over te nemen door een andere programmeur? Hoe borg je dat? Op zich is het een prima optie, maar ik adviseer het meestal op de wat langere termijn. Voor de initiële ontwikkeling is een bureau vaak een veiligere optie.’

8. Van wie is de broncode?

‘Als laatste advies wil ik meegeven heel scherp te zijn op de voorwaarden van de ontwikkelaar. Hoe ziet bijvoorbeeld hun nazorgconstructie eruit? Hoe gaan ze om met bugs, met onderhoud of met vragen nadat de software is opgeleverd? Dat nagaan, of van tevoren goed afspreken, kan tegenvallers voorkomen. Maar ga ook absoluut in gesprek over het intellectueel eigendom. De meeste bureaus hebben standaard in hun voorwaarden staan dat de broncode hun eigendom blijft. Dat betekent dat je niet makkelijk kan switchen van ontwikkelaar. Maar er zijn absoluut bureaus die bereid zijn om hier uitzonderingen op te maken. Ik zou dit gesprek altijd aangaan voor de opdracht definitief is. Hetzelfde geldt overigens als je besluit een zzp-er in te huren of wanneer je iemand aanneemt. Let ook dan goed op welke voorwaarden er van toepassing zijn. De broncode wordt essentieel voor je bedrijf. Daar moet je zuinig op zijn.’

Wil je meer weten over Beeproger?