De vragen die ik stel voordat ik je app bouw

De meeste gesprekken over een nieuwe app beginnen bij het scherm. Iemand heeft een idee, heeft er schetsen bij, weet al welke knoppen waar moeten staan, en wil weten wat dat kost. Ik snap die volgorde wel, want het is het enige deel van software dat je kunt zien. Maar het is niet het deel dat bepaalt of je straks iets hebt waar je bedrijf beter van wordt.

Ik bouw en run zelf Altrady, een handelsplatform voor crypto dat sinds 2018 draait en inmiddels door meer dan 130.000 traders gebruikt wordt. Daaronder zit Coinray, de marktdata-API die Altrady voedt. En daarnaast Kinfolder, een familiemap voor testamenten, accounts en instructies. Ik heb jarenlang ontwikkelteams geleid en code van junioren en senioren beoordeeld. Wat ik daarvan heb overgehouden is niet zozeer een lijst met technische eisen, maar een paar vragen die ik altijd stel voordat er ook maar één regel code geschreven wordt.

Waarom bouw je dit?

Dit is de vraag waarvan ik zou willen dat klanten hem zelf stelden. Waarom bouw je deze app? Welke bedrijfswaarde levert het op? Welk probleem los je op?

Het klinkt bijna te simpel om hardop te vragen, en juist daarom wordt hij overgeslagen. Maar het antwoord scheidt twee soorten projecten van elkaar. Er is bouwen omdat je iets wilt bouwen, en er is bouwen om verschil te maken in een bedrijf. Beide kosten evenveel geld. Slechts één van de twee betaalt zich terug.

Als het antwoord is “onze concurrent heeft ook een app” of “we willen iets met AI doen”, dan is dat geen probleem dat je oplost, dat is een gevoel dat je hebt. Daar kan ik software omheen bouwen, maar ik kan niet beloven dat er daarna iets verandert. Als het antwoord is “mijn mensen typen elke dag dezelfde gegevens over uit drie systemen en we maken daar fouten mee”, dan hebben we iets om aan te werken. Dan weet ik waar ik op moet sturen, en weet jij achteraf of het gelukt is.

Wat maakt iemand een goede ontwikkelaar voor bedrijfssoftware?

Er wordt veel gepraat over talen, frameworks en certificaten. Voor bedrijfssoftware vind ik dat niet de belangrijkste maatstaf. De goede ontwikkelaar voor dit werk is degene die bedrijfswaarde blijft bijhouden.

Dat is een praktische eigenschap, geen houding. Het komt neer op één afweging die de hele dag door terugkomt: kan ik vandaag iets opleveren dat genoeg waarde toevoegt, of ga ik weken besteden aan iets wat niemand gebruikt? Een ontwikkelaar die die vraag niet stelt, bouwt precies wat er op het lijstje staat. Dat voelt fijn tijdens het project en het valt pas op als je maanden later kijkt naar welke functies daadwerkelijk aangeklikt worden.

Je herkent het in een gesprek aan hoe iemand reageert op jouw wensenlijst. Iemand die alles enthousiast overneemt en er een prijs onder zet, heeft geen oordeel toegevoegd. Iemand die vraagt wat je zou weglaten als je over zes weken live moest, denkt mee over jouw kant van de rekening.

Wat heb je eigenlijk nodig op dag één?

Dit is waar veel ondernemers zichzelf tegenhouden. Ze wachten tot alles klopt: de naam, het logo, het domein, de complete functielijst. Dat wachten kost meer dan het oplevert.

Wat je op dag één echt nodig hebt is een probleem om op te lossen en een ruw idee van de oplossing. Meer niet. Een domeinnaam en een productnaam zijn prettig om te hebben, maar niet noodzakelijk om te beginnen, zolang je flexibel bent over die naam. Namen verander je later nog. Het idee en de oplossing zijn wat je te verdedigen hebt; dat is het deel waar een ander niet zomaar omheen loopt.

Het idee en de oplossing zijn je voorsprong. De naam is een label dat je er later op plakt.

Dat betekent niet dat je onvoorbereid binnen hoeft te komen. Het betekent dat voorbereiding iets anders is dan je waarschijnlijk denkt. Kom met de situatie die je wilt veranderen, hoe die er nu uitziet, wie er last van heeft en wat het je kost dat het zo blijft. Daar kan ik mee werken. Een map vol schermontwerpen zonder dat verhaal erbij is lastiger, want dan weet ik wel wat je gebouwd wilt hebben, maar niet waarom het zo moet.

En het geld?

Hier hou ik het in dit stuk kort, want de offerte zelf verdient zijn eigen uitleg. Mijn uitgangspunt: een vaste prijs, met duidelijke verwachtingen over wat er geleverd wordt.

Dat is geen trucje om goedkoper te lijken. Het is een manier om het risico op de juiste plek te leggen. Als ik een vaste prijs afgeef, is het mijn probleem als ik verkeerd inschat hoeveel werk iets is. Bij een open urenrekening is dat jouw probleem, terwijl jij degene bent die het minst kan beoordelen of die uren nodig waren. Wat er tegenover die vaste prijs moet staan is scherpte over de scope: wat zit erin, wat zit er niet in, en wat gebeurt er als je onderweg van richting wilt veranderen.

Wat je hiermee kunt doen

Je hoeft dit niet te gebruiken om mij te beoordelen. Gebruik het op iedereen met wie je praat, inclusief het bureau dat je al jaren kent.

Stel de waarom-vraag hardop en let op wat er gebeurt. Sommige mensen beginnen meteen over techniek, sommige beginnen over jouw klanten. Vraag wat ze zouden weglaten. Vraag wat ze nodig hebben van jou om te kunnen beginnen. En kijk of je een vaste prijs met een scherpe scope krijgt, of een schatting die alle kanten op kan.

Als je zelf nog niet scherp hebt wat het probleem is dat je oplost, is dat trouwens geen reden om het gesprek uit te stellen. Dat is vaak precies het gesprek dat je nodig hebt. Wil je die een keer voeren, dan hoor ik graag waar je nu tegenaan loopt.