Wat heb je nodig voordat je een bouwpartij benadert?

Blijft je verhaal vaag, dan vult een bureau de gaten zelf in: met aannames over de doelgroep, met een ruime scope uit voorzichtigheid, of met een schatting die achteraf niet blijkt te kloppen. Dat leidt tot twee dingen die je liever voorkomt. Een offerte die hoger uitvalt dan nodig, omdat er marge is ingebouwd voor onduidelijkheid. En een eerste versie die net niet is wat je bedoelde, waardoor een deel opnieuw gebouwd moet worden.

Dat is geen kwestie van slimmer nadenken over techniek. Je hoeft niet te weten hoe iets gebouwd wordt, dat is het werk van de bouwpartij. Je moet wel helder krijgen wat er gebouwd moet worden en waarom. De vijf punten hieronder zijn de kern van wat een bouwpartij nodig heeft om je serieus te kunnen helpen in plaats van te gokken. Zet ze op papier, bijvoorbeeld met de projectbrief-generator, en het eerste gesprek gaat meteen over de juiste dingen.

Voordat je een bouwpartij benadert helpt het om het probleem dat je oplost in één zin te zetten, zonder de oplossing er meteen in te stoppen. Niet "een app voor planning", maar bijvoorbeeld "zzp'ers verliezen tijd aan het handmatig plannen van hun week tussen meerdere klanten door". Die scherpte dwingt je om te kiezen voor wie je dit oplost en wat er nu misgaat, in plaats van in vage termen te blijven hangen.

Test de zin op iemand buiten je vakgebied. Snapt diegene binnen een paar seconden wat het probleem is, dan is de zin scherp genoeg om mee naar een intake te nemen.

Bij een boekingsapp is dat het maken van een reservering, bij een planningstool het inplannen van een taak, bij een marktplaats het vinden en afronden van een match. Beschrijf die flow in een paar stappen, van het moment dat iemand binnenkomt tot het moment dat het doel is bereikt. Alles wat niet direct bijdraagt aan die flow is voorlopig bijzaak.

Je hoeft geen ontwerper te zijn om dit op te schrijven. Een paar zinnen, of een ruwe schets op papier, is vaak al genoeg om een bouwpartij te laten zien waar de kern van je idee zit. Hoe je dat overbrengt, staat uitgebreider in hoe je je idee uitlegt aan een developer.

Door in de voorbereiding al te veel functies als verplicht te bestempelen, groeit de scope voor er iets gebouwd is. Splits je lijst in twee kolommen en wees daar streng in.

Twijfel je waar de grens ligt? De mvp-scope-slicer helpt die knoop functie voor functie doorhakken.

Vaak moet een nieuwe app praten met een boekhoudpakket, een CRM, een Excel-bestand vol klantgegevens, of een bestaand inlogsysteem. Breng dat in kaart voordat je een bouwpartij benadert: welke systemen zijn er, is er een API of moet er handmatig geëxporteerd worden, en wie heeft toegang tot de data die nodig is.

Dit is een van de meest onderschatte oorzaken van een uitlopende offerte. Een koppeling die je vergeet te noemen, kan achteraf meer werk kosten dan de rest van de app bij elkaar. Noem hem liever te vroeg dan te laat, ook als je zelf nog niet weet hoe het technisch moet.

Voor wie bouw je dit, in één zin: een interne afdeling, een groep consumenten, een specifieke branche? En hoe vroeg wil je iets werkends zien: een klikbaar prototype van je kernflow om te testen of het idee klopt, of denk je in een langer traject met meerdere fases?

Beide zijn legitiem, maar een bouwpartij richt het gesprek anders in afhankelijk van je antwoord. Bij OneDayBuild werken we vanuit het eerste: in een werkdag een werkend prototype van je kernflow, zodat je snel weet of je door moet bouwen.

Een brief die deze vijf punten dekt, hoeft niet perfect te zijn. Ze is genoeg om een bouwpartij te laten reageren op wat je daadwerkelijk bedoelt, in plaats van op aannames.