Overarch

Dank voor je reactie, Hans. Op één punt heb je gelijk: ik heb het prototype te eenzijdig neergezet als gespreksmiddel. Het is ook denkgereedschap, want al bouwend leg je aannames bloot waarvan je niet wist dat je ze had. Wel denk ik dat mijn stuk iets anders zegt dan je erin leest. Ik bedoelde niet dat prototypes mislukte eindproducten zijn, maar dat ze geen bewijs zijn. Dat is voor mij iets anders. Tegen itereren heb ik niets, ik pleit er juist voor. Ons verschil zit misschien in het type prototype waar we het over hebben. Een wegwerpprototype bouw je om te leren en gooi je daarna weg. Een evolutionair prototype is een eerste versie die doorgroeit naar het product. Jouw punt over fouten die er tijdens het opschalen uit gaan, gaat wat mij betreft op voor het tweede type. Mijn kritiek gaat vooral over wat er gebeurt zodra het eerste als het tweede wordt behandeld, en dat kom ik in de praktijk steeds vaker tegen: het prototype wordt niet weggegooid maar gaat in productie. Het werkt immers. De rekening komt dan later. Daar komt bij dat zo'n prototype meestal maar één aanname toetst, namelijk of het te bouwen valt. Dat is zelden de aanname waar een startup op omvalt. Uitvoeringsfouten schaal je er inderdaad uit, maar een verkeerde aanname schaal je mee. En dat snellere paard: ik zou zeggen dat Ford niet bij de auto uitkwam doordat hij het paard afwees, maar doordat hij een betere aanname had over het onderliggende probleem dan de bestaande oplossing belichaamde. Ook die sprong begon dus bij de klant, alleen bij hun probleem en niet bij hun oplossing. Ik ben dus niet tegen de sprong, ik zoek naar het fundament eronder. Benieuwd hoe jij dat ziet.

Niet omdat de tools slecht zijn. Ze zijn juist heel goed. De meeste startups falen omdat ze iets bouwen waar niemand op zit te wachten. Dat was altijd al zo, maar het bouwen zelf vormde de rem. Het kostte maanden en tienduizenden euro's, dus legde je je idee eerst voor aan tien potentiële klanten. Die rem is verdwenen en er is niets voor teruggekomen. Wat overblijft is: een idee, meteen een prototype, en dat prototype vervolgens beschouwen als bewijs dat het idee klopte. Een prototype is geen bewijs. Het is gereedschap voor een gesprek, en dat gesprek levert het bewijs. De volgorde die wel werkt: 1. Kies eerst je markt, dan pas je idee. Een goed idee in een onverschillige markt verliest van een middelmatig idee in een wanhopige markt. 2. Maak je aanname toetsbaar. "Mensen hebben moeite met urenregistratie" is een observatie. "Installatiebedrijven met tien monteurs besteden wekelijks een halve dag aan het overtypen van werkbonnen" is controleerbaar. 3. Vraag naar het verleden. Op "zou je dit gebruiken?" krijg je beleefdheid. Op "vertel eens over de laatste keer dat je hiermee te maken had" krijg je informatie. 4. Vraag om geld voordat het product bestaat. Meningen zijn gratis. Een aanbetaling is het enige harde bewijs. 5. Bouw alleen de kern en leg die voor aan vijf mensen uit je doelgroep. En dan de manier waarop je bouwt: Het probleem is niet dat AI slechte code schrijft. De code doet precies wat je hebt gevraagd. Het probleem is dat je over één signaal beschikt: werkt het of niet. En dat staat na één opdracht al op groen. Een ontwikkelaar heeft daaronder een filter die niets met werken te maken heeft. Klopt dit datamodel? Waar wordt gecontroleerd of iemand hier wel bij mag? Hij ziet bovendien wat er ontbreekt, en wat afwezig is valt niet op zolang je niet weet wat er hoort te staan. Of een functie werkt merk je onmiddellijk, maar een kwetsbaarheid pas wanneer iemand er misbruik van maakt. Het verschil zit dus niet in snelheid. Jij bouwt in een weekend wat een ontwikkelaar in een weekend bouwt. Het verschil zit in wat er over zes maanden nog overeind staat.

Anders, namelijk: de vraag is niet hoe vaak je nee zegt, maar op welk moment. Nee zeggen aan de voorkant, in je positionering, je doelgroepkeuze en je assortiment, kost je vrijwel niets. Je stuurt daar op selectie voordat er verwachtingen zijn gewekt. Nee zeggen tegen iemand die al klant is, kost je marge, doorlooptijd, retouren, supportcapaciteit en vaak een negatieve review. Dezelfde nee, een ander moment, een volstrekt andere rekening. Zodra je ja hebt gezegd, verandert je rol. Er ligt dan een belofte, en een discussie over wie gelijk heeft is vrijwel altijd duurder dan het probleem simpelweg oplossen. Zeker wanneer je dat afzet tegen de kosten van het werven van een nieuwe klant. Loop je in de uitvoering structureel aan tegen klanten die niet bij je passen? Behandel dat dan niet als een servicevraagstuk, maar als een selectievraagstuk. Je nee had eerder moeten komen.

Om heel eerlijk te zijn, zou ik dit niet zelf bouwen voor WordPress. Daar zijn namelijk al genoeg spelers die dit heel goed geregeld hebben. Ik heb even voor je gezocht op kant-en-klare WordPress oplossingen die goed aansluiten bij wat je zoekt en ben uitgekomen bij ElasticPress. Die is wel de moeite waard om eens te onderzoeken, vooral omdat dit een managed hosting service is op basis van Elasticsearch.

Ik ben hier net lid geworden en wil beginnen met een onderwerp waar ik in mijn werk vrijwel dagelijks tegenaan loop. Wat hieronder staat is mijn eigen kijk erop, gebaseerd op wat ik in de praktijk zie. Ik hoop dat iemand er iets aan heeft, en ik hoor het graag als jullie het anders aanpakken. In juni 2025 voorspelde Gartner dat ruim veertig procent van de agentic AI-projecten vóór eind 2027 geannuleerd zou worden. Als oorzaken noemden ze oplopende kosten, onduidelijke businesswaarde en te weinig grip op de risico's. Opvallend genoeg gaat het in dat rijtje nergens over de techniek zelf. Die projecten sneuvelden omdat niemand kon uitleggen wat ze opleverden. Ik kom zelf uit de software engineering en bouw maatwerk en koppelingen voor ondernemers. Dat patroon herken ik uit de praktijk. Daarom zou ik altijd beginnen bij een proces waarvan je de kosten kunt onderbouwen. Houd twee weken bij welke handelingen je steeds herhaalt, tel de tijd bij elkaar op en zet er je eigen uurtarief naast. Kom je uit op twintig minuten per week, dan is het gesprek daarmee klaar. Gaat het om vijf uur, dan weet je meteen hoeveel je mag investeren. Zo'n urenlijst laat je trouwens maar de helft zien. Tijdproblemen herken je snel, want je doet hetzelfde werk telkens opnieuw. Procesproblemen zijn lastiger te zien: aanvragen die blijven liggen, opvolging die van iemands geheugen afhangt, geen zicht op waar het spaak loopt. Dat tweede type kost vaak meer, alleen komt het nergens op een urenlijst terug. Vraag je bij elk proces dus ook af welk cijfer je nu mist om te kunnen sturen. Pas daarna kies je de techniek. Levert een stap bij dezelfde invoer altijd dezelfde uitkomst op, denk aan een factuur boven een bepaald bedrag die eerst langs jou moet, dan is een koppeling goedkoper en betrouwbaarder dan welk taalmodel dan ook. AI komt pas tot zijn recht bij (rommelige) invoer waar je normaal gesproken zelf even over na moet denken: een mail waarin een klant vier vragen door elkaar stelt, of een ingescande pakbon met een aantekening in de kantlijn. In de gesprekken die ik voer zie ik ondernemers AI juist bijna altijd op die eerste categorie loslaten. Ga je met een externe partij in zee, dan zou ik op precies hetzelfde letten. Gartner waarschuwt in datzelfde bericht voor "agent washing", maar wat ik vaker tegenkom is de partij die je vraag afwerkt als een ticket. Jij vraagt om X, zij bouwen X en factureren X, en onderweg heeft niemand uitgerekend of X zichzelf ooit terugbetaalt. Let er in een eerste gesprek daarom op of ze een serieuze discovery doen. Krijg je vragen over je proces, je cijfers en wat je nu misloopt, of gaat het meteen over hun oplossing? Vraag ook wat ze je zouden afraden, en wat er gebeurt als het systeem er een keer naast zit. Overigens kun je een hoop zelf in elkaar klikken met Make, Zapier, n8n of een ander no-code platform, en voor één losstaande flow zou ik dat ook gewoon doen. Het bouwen is zelden het dure deel. Het onderhoud is dat wel, want een leverancier past zijn API aan, je flow valt stil zonder dat je daar een melding van krijgt en je komt erachter op het moment dat een klant belt. Weeg daarom af wat het je kost als dat gebeurt en je het zelf moet oplossen. Hangt er een facturatie- of klantproces aan, dan is een SLA met een afgesproken reactietijd dat geld waard. Gaat het om je eigen inbox, dan pak je het op een rustig moment zelf op. Ik ben benieuwd of hier mensen zijn die een automatisering na een paar maanden weer hebben uitgezet. Wat ging daar mis?

Wij hebben het zoeken zelf gebouwd. Twee dingen vangen we daarmee op. Typefouten: iemand die een lange vakterm net verkeerd intypt, krijgt toch de juiste artikelen. Betekenis: wie bijv. zoekt op "auto van de zaak" komt ook bij informatie over bijtelling uit, ook al staat die term er niet letterlijk in. Onder de motorkap: het Levenshtein-algoritme voor de typefouten, en vector embeddings voor de betekenis.