MODULE 5 — BUILDR FOUNDATION [START OP SLIDE 1] Welkom bij Module 5 van Buildr Foundation. In deze module leer je hoe je van een werkend systeem naar een eerste klant en een concreet aanbod gaat. [KLIK — NAAR SLIDE 2] Je kan inmiddels systemen bouwen. De volgende vraag is net zo belangrijk: welke problemen zijn het waard om als eerste op te lossen, in de zin van wat een bedrijf er daadwerkelijk voor betaalt. Niet elk probleem dat je kan oplossen, is ook een probleem dat snel verkoopt. Er zijn drie simpele vragen die je jezelf stelt bij elke kans die je tegenkomt. Eén: voelt het bedrijf dit probleem nu al, zonder dat jij het eerst moet uitleggen. De webshop die klanten kwijtraakt omdat reacties op vragen dagen duren, voelt dat al elke week in gemiste verkopen. [KLIK — NAAR SLIDE 3] Daar hoef je niemand te overtuigen dat het een probleem is. Twee: kan je dit binnen een paar weken laten werken, niet binnen een paar maanden. Hoe sneller iemand resultaat ziet, hoe makkelijker het is om vertrouwen te winnen en betaald te worden. Drie: kan je in één zin uitleggen wat het oplost. Als je drie alinea's nodig hebt om uit te leggen wat een systeem doet, is het waarschijnlijk te ingewikkeld om als eerste aanbod te verkopen. De drie systemen die je in Module 4 hebt gebouwd, scoren op alle drie goed. [KLIK — NAAR SLIDE 4] Een lead qualifier, een outreach-systeem, een contentworkflow: het bedrijf voelt het probleem al, je kan het snel laten werken, en je kan het in één zin uitleggen. Vergelijk dat met iets als "een volledig AI-platform voor de hele organisatie". Niemand voelt dat probleem acuut, het duurt maanden, en niemand snapt in één zin wat het oplost. Dat verkoop je niet als eerste aanbod, dat verkoop je pas als je al een paar kleinere successen hebt staan. Naast welk probleem, is er nog een vraag die net zo belangrijk is: aan wie je dat voorstelt. De makkelijkste eerste klant is niet een onbekend bedrijf dat je koud moet benaderen, maar iemand binnen je eigen bereik. [KLIK — NAAR SLIDE 5] Een oud-werkgever, een familiebedrijf, een ondernemer die je kent via vrienden of een lokale community. Bij hen heb je al een basis aan vertrouwen, en dat vertrouwen vervangt in het begin het bewijs dat je later via resultaten en reviews gaat opbouwen. Begin daar, niet bij een willekeurig bedrijf dat je nog nooit hebt gesproken. De praktische conclusie: zoek bij iemand die je al kent naar het probleem dat ze nu al voelen, dat je snel kan laten werken, en dat je in één zin kan uitleggen. Dat is de combinatie waarmee je begint: een bekende, een gevoeld probleem, een snelle oplossing. [KLIK — NAAR SLIDE 6] De beste kansen kondigen zichzelf niet aan met de woorden "ik heb een AI-probleem". Ze klinken veel gewoner, en je moet leren ze te herkennen in een doodnormaal gesprek. Luister naar zinnen als: "dat doen we nog steeds met de hand", "dat kost ons elke week uren", "daar lopen we elke keer weer tegenaan". Dat zijn geen klachten in de lucht, dat zijn signalen van een probleem dat al pijn doet. Zodra je zo'n signaal hoort, is je taak niet om meteen een oplossing te verkopen. Je taak is om eerst goed door te vragen, zodat je het probleem scherp krijgt en weet of het de moeite waard is. [KLIK — NAAR SLIDE 7] Een voorbeeld van zo'n gesprek. Klant: "We krijgen zoveel aanvragen binnen dat we soms dagen nodig hebben om te reageren." Jij: "Hoeveel van die aanvragen lopen daardoor denk je dood, omdat mensen niet op tijd antwoord krijgen?" Klant: "Eerlijk gezegd, een flink deel waarschijnlijk." Jij: "En stel dat elke aanvraag binnen een paar minuten een persoonlijk antwoord kreeg, in plaats van na een paar dagen, zou dat verschil maken?" [KLIK — NAAR SLIDE 8] Klant: "Absoluut, dat zou een hoop opleveren." In drie zinnen heb je nu het probleem (te trage reactietijd), de impact (verloren aanvragen) en de bevestiging dat een oplossing waarde heeft. Dat is alles wat je nodig hebt om te weten of dit een kans is die het waard is om op te pakken. De praktische conclusie: train jezelf om te luisteren naar "dat doen we nog met de hand" en "dat kost ons tijd", en stel daarna twee simpele vragen: hoeveel kost dit nu, en zou een oplossing verschil maken. De antwoorden op die twee vragen vertellen je alles. [KLIK — NAAR SLIDE 9] Je hebt een kans gevonden en scherp gekregen. Nu moet je dat omzetten in een voorstel dat een bedrijf daadwerkelijk overtuigt, en dat hoeft geen lang document te zijn. Vier onderdelen zijn genoeg: het probleem in hun eigen woorden, de oplossing in gewone taal, wat het oplevert, en wanneer het klaar is. Een voorbeeld, gebaseerd op het recruitmentbureau uit Module 4. "Op dit moment kost het personaliseren van elk eerste bericht aan nieuwe kandidaten zoveel tijd, dat jullie team minder kandidaten per week kan benaderen dan jullie zouden willen. Ik bouw een systeem dat voor elke nieuwe kandidaat automatisch een persoonlijk eerste bericht voorbereidt, klaar voor controle voordat het verstuurd wordt. Binnen twee weken staat dit live. [KLIK — NAAR SLIDE 10] Op basis van het aantal kandidaten dat jullie nu per week benaderen, verwacht ik dat dit jullie capaciteit ruimschoots vergroot, zonder dat daar extra mensen voor nodig zijn." Kijk wat hier ontbreekt: geen technische termen, geen opsomming van tools, geen jargon over AI-modellen. Alleen het probleem dat de klant zelf voelt, de oplossing in mensentaal, en een concrete verwachting. Je kan een eerste versie van zo'n voorstel ook laten schrijven met Claude, met precies dezelfde scherpe-prompt aanpak die je in Module 1 hebt geleerd. Een voorbeeld: "Schrijf een kort voorstel voor [bedrijfsnaam], een recruitmentbureau. Hun probleem: het personaliseren van outreach-berichten kost te veel tijd, waardoor ze minder kandidaten per week kunnen benaderen. [KLIK — NAAR SLIDE 11] Mijn oplossing: een systeem dat automatisch persoonlijke eerste berichten voorbereidt, klaar voor controle. Toon: vriendelijk, direct, geen jargon. Sluit af met een duidelijke tijdlijn." Net als bij elke andere prompt geldt: hoe scherper de context die je meegeeft, hoe minder je achteraf nog moet aanpassen. Niet elk voorstel krijgt meteen een ja, en dat is normaal. Twee veelvoorkomende reacties zijn een duidelijk nee, of een aarzelend "ik denk er nog even over na". [KLIK — NAAR SLIDE 12] Bij een duidelijk nee is een korte, vriendelijke reactie genoeg: "Helemaal goed, mocht het probleem later toch weer gaan knagen, hoor ik het graag." Geen druk, geen overtuigingspoging, gewoon de deur open laten. Bij twijfel helpt het om te vragen wat precies de twijfel is, in plaats van meteen harder te verkopen: "Wat zou je nog willen weten om hier zeker van te zijn?" Vaak blijkt de twijfel niet over de oplossing zelf te gaan, maar over iets simpels als tijd of prioriteit, en dat los je op met geduld, niet met druk. De praktische conclusie: een goed voorstel is kort, in de taal van de klant, en bevat altijd vier dingen, het probleem, de oplossing, de opbrengst en de tijdlijn. En een nee of een aarzeling is geen mislukking, het is gewoon onderdeel van het proces, rustig en zonder druk afgehandeld. [KLIK — NAAR SLIDE 13] Je hebt een akkoord. Dit is het moment waarop veel beginners zichzelf in de problemen werken, omdat ze niet helder hebben afgesproken wat er wel en niet bij het project hoort. Zonder die grens vraagt een klant na een paar weken steeds iets extra, zonder dat daar iets tegenover staat, en zit jij ineens veel meer werk te doen dan waarvoor je was ingehuurd. De oplossing is simpel: schrijf de grens net zo concreet op als het voorstel zelf. Een voorbeeld, bij het marketingbureau uit Module 4. "Inbegrepen: het automatisch voorbereiden van conceptposts op basis van de vastgelegde contentpijlers, klaar voor goedkeuring. Niet inbegrepen: het bedenken van nieuwe contentpijlers of een nieuwe contentstrategie, het maken van afbeeldingen of video's, en het beheren van advertentiebudgetten." [KLIK — NAAR SLIDE 14] Twee zinnen, en iedereen weet precies waar de grens ligt. Dat betekent niet dat je nooit iets extra's doet. Het betekent dat je het bewust doet. Als een klant tijdens het project iets vraagt dat buiten de afspraak valt, is een simpele, vriendelijke reactie genoeg: "Dat is een goed idee, en dat kan ik oppakken als een vervolgstap, los van de conceptposts die we nu hebben afgesproken." Daarmee zeg je geen hard "nee", maar je laat ook niet ongemerkt het project groeien zonder dat daar iets tegenover staat. De praktische conclusie: leg de grens net zo concreet vast als de oplossing zelf, in twee zinnen, inbegrepen en niet inbegrepen. En als er iets buiten die grens wordt gevraagd, benoem je dat gewoon, rustig, als een vervolgstap in plaats van een gratis extra. [KLIK — NAAR SLIDE 15] De vraag die bijna iedereen in het begin laat struikelen: wat vraag ik hiervoor. Te laag, en je werkt je kapot voor te weinig. Te hoog zonder onderbouwing, en je verliest het vertrouwen voordat je bent begonnen. De fout die de meeste beginners maken, is prijzen op basis van uren. [KLIK — NAAR SLIDE 16] Hoeveel tijd heb ik erin gestoken, dus dat reken ik door. Het probleem daarmee is dat een systeem dat je dankzij Claude Code in een paar uur bouwt, voor de klant net zoveel waarde kan hebben als iets dat een traditioneel bureau in drie weken zou bouwen. Reken je op uren, dan beloon je jezelf voor traagheid, en straf je jezelf voor efficiëntie. Prijs daarom op waarde, niet op uren. [KLIK — NAAR SLIDE 17] Kijk naar wat het probleem het bedrijf nu kost, en prijs een fractie van die waarde. Terug naar het verbouwingsbedrijf uit Module 4: stel dat ze door trage reacties elke maand een goede aanvraag verliezen aan een snellere concurrent, en zo'n project is voor dit bedrijf al snel een paar duizend euro waard. Als je systeem er per maand zelfs maar één extra aanvraag binnenhaalt die anders verloren was gegaan, is de waarde voor het bedrijf vele malen hoger dan wat jij ervoor vraagt. Een prijs van pakweg tweehonderdvijftig euro per maand voor onderhoud, plus een eenmalig opstartbedrag, is dan een vanzelfsprekende investering, ongeacht hoeveel uur jij er daadwerkelijk in hebt gestoken. [KLIK — NAAR SLIDE 18] Een simpele structuur die voor de meeste eerste projecten werkt: een eenmalig bedrag voor het bouwen en live zetten, en een klein vast bedrag per maand voor onderhoud en hosting. Dat eenmalige bedrag baseer je op de waarde die je net hebt berekend, niet op een uurtarief. Het maandelijkse bedrag is meestal bescheiden, het dekt de tijd die je in Video 4.5 hebt gezien: een paar minuten per maand aan controle en bijsturen. De praktische conclusie: bereken eerst wat het probleem het bedrijf nu kost, prijs een deel van die waarde, en vraag niet aan jezelf hoeveel uur je erin hebt gestoken, maar aan het bedrijf hoeveel het probleem ze waard is om opgelost te hebben. [KLIK — NAAR SLIDE 19] Even stilstaan bij waar je nu staat. Je begon bij het idee dat bedrijven betalen voor AI-kennis, en leerde al in de eerste video dat dat niet klopt: ze betalen voor een probleem dat is opgelost. Daarna leerde je denken als een builder in plaats van als een leerling, de bouwblokken zien achter elk systeem, API's en webhooks zonder schrik begrijpen, en zelf een systeem ontwerpen voordat je er een tool voor opent. Daarna heb je daadwerkelijk gebouwd. Drie volledige systemen, van ontwerp tot iets dat live kan draaien, met Claude Projects en Claude Code als gereedschap, veilig omgaan met echte data, en een lichte gewoonte om alles gezond te houden. [KLIK — NAAR SLIDE 20] En in deze laatste module heb je geleerd te herkennen welk probleem het waard is om als eerste op te lossen, bij wie je begint, hoe je een voorstel schrijft dat in de taal van de klant blijft, hoe je grenzen stelt, hoe je omgaat met een nee, en hoe je prijst op waarde in plaats van op uren. Dat is geen lijstje met kennis meer. Dat is een herhaalbaar proces, van een probleem dat je ergens tegenkomt, tot een werkend systeem, tot een klant die daarvoor betaalt. Je hebt dat proces nu een paar keer gezien, met verschillende bedrijven en verschillende problemen, en dat is precies de bedoeling: niet één trucje onthouden, maar een patroon dat overal opnieuw werkt. [KLIK — NAAR SLIDE 21] Wat je hierna doet, is aan jou. Misschien is het je eigen netwerk afgaan op zoek naar het eerste echte probleem. Misschien is het een van de drie systemen uit deze cursus rechtstreeks aanbieden aan iemand die je kent. Wat het ook is, je hebt nu alles wat je nodig hebt om te beginnen, niet om nog een cursus te volgen, maar om daadwerkelijk te bouwen.