De plek waar mensen hun ideeën met de wereld delen

Ik ben niet in dit onderwerp gekomen als iemand die gisteren voor het eerst een neurale netwerk ontdekte en besloot een "startup te starten".

Ik heb ongeveer twintig jaar ervaring in IT, waarvan meer dan tien jaar in een grote bank. Ik heb gewerkt met informatiesystemen, implementaties, services, infrastructuur, interne portalen, CRM en alles wat gewoon tussen de gebruiker, het bedrijfsleven en de technische realiteit staat. Daarbij ben ik nooit een ontwikkelaar geweest in de klassieke zin.

Misschien is dat de reden waarom AI‑tools me niet als een speelgoed voor codegeneratie hebben aangetrokken. Voor mij is het een kans om eindelijk ideeën snel te testen die anders vastliepen tussen "moet worden gedaan" en "er is een ontwikkelteam voor nodig".

Een andere factor is dat ik in Nederland woon. Hier zie je heel duidelijk hoe internationaal de IT‑werkplek is geworden. Niet alleen in Amsterdam, maar op een klein stukje land om je heen kunnen er specialisten uit verschillende landen zijn, die verschillende talen spreken en werken voor bedrijven in andere tijdzones. Soms lijkt het bijna komisch: een zogenaamd expat uit Vietnam, die in Rusland heeft gewoond, werkt in Nederland voor Australië. En dat is geen uitzondering, maar gewoon het dagelijks leven.

Wanneer een ontwikkelaar een project toont, heeft hij een gebruikelijke route: GitHub, README, demo, documentatie. Niet perfect, maar duidelijk. Een andere ontwikkelaar opent het repository en begrijpt ongeveer wat er voor hem ligt.

Bij vibe‑coders is het iets anders.

Iemand hoeft geen professionele ontwikkelaar te zijn. Hij opent Cursor, Lovable, Bolt of Claude en legt in woorden uit wat hij wil krijgen. "Maak een formulier", "repareer het scherm", "controleer de fout". Zo bouwt hij het product: via gesprek, verduidelijking en nieuwe pogingen.

En dan ontstaat een vreemde val.

Het product bestaat al. Het kan ruw zijn, maar het bestaat. En het is moeilijk om het goed te laten zien. GitHub is te technisch. De landing page is te reclame‑achtig. Uiteindelijk moet de auteur kiezen tussen "dit is mijn code" en "dit is een mooi scherm", terwijl hij eigenlijk iets heel anders nodig heeft: uitleggen wat hij heeft gedaan en waarom.

In het begin dacht ik dat ik een catalogus maakte. Na een tijd besefte ik: er zijn al genoeg catalogi. Het probleem is niet dat er geen plek is om een link te plaatsen. Het probleem is dat het moeilijk is om het project uit te leggen.

Zo ontstond storevi.be. Ik zou het nu niet beschrijven als een catalogus van AI‑tools, maar als een plek waar een klein project in menselijke taal kan worden uitgelegd.

En "menselijk" betekent voor mij hier niet alleen eenvoudige woorden, maar ook verschillende talen. Als de auteur het project in het Russisch of Engels beschrijft, moet het platform zelf helpen het aan mensen uit een ander land te tonen. Anders wordt de drempel weer hoog: het is niet genoeg om een product te maken, je moet ook weten hoe je het op de juiste manier vertelt in de taal van de toekomstige gebruiker.

Ja, er is een vergelijking met Product Hunt onvermijdelijk, omdat ze bekend zijn als een lanceringplatform. Maar ik probeer niet "een andere lancering van de dag" te maken. Ik vind het interessanter om het moment vóór de grote lancering te beschrijven, wanneer de auteur nog zelf probeert te begrijpen wat hij heeft gedaan, maar al klaar is om het aan mensen te tonen.

Waarom GitHub en een landing page de taak niet oplossen

GitHub is geweldig wanneer een project door een ontwikkelaar wordt bekeken. Maar voor iemand zonder technische achtergrond is het meer een instrumentenpaneel. Er is veel belangrijks, maar het is niet altijd duidelijk wat er bij het product zelf hoort.

Een vibe‑coder heeft een andere behoefte. Hij hoeft niet te beginnen met "dit is mijn repository". Hij moet beginnen met een gewone beschrijving: wat ik doe, voor wie en wat al werkt.

Met een landing page is het tegenovergestelde probleem. Het kan te mooi lijken. Je kunt schrijven "automatiseer je bedrijf met AI" en een mooie knop plaatsen. Maar wat er echt is gedaan, blijft onduidelijk.

Op storevi.be besloot ik te beginnen met wat vibe‑coders al gewend zijn: met een beschrijving in woorden. De auteur maakt een kaart niet via een lange technische vragenlijst, maar via een verhaal over het project. Vervolgens helpt het systeem dit in een normale vorm te brengen en stelt het een interview op.

Het interview mag niet standaard zijn. Als je iedereen hetzelfde vraagt, krijg je weer een saaie vorm.

Ik wil dat AI naar een specifiek project kijkt. Als het een verhuurservice is, moeten de vragen gaan over vertrouwen en echte deelnemers. Als het een tool voor het testen van kandidaten is, over de kwaliteit van de beoordeling en modelfouten. Het doel is niet een checklist, maar om de auteur belangrijke details te laten onthullen.

Eerste fout: ik begon een combine te bouwen

De grootste dwaasheid was bijna klassiek. Ik begon te snel een groot product te bouwen.

In mijn hoofd leek alles logisch: projecten, auteurs, artikelen, moderatie, AI‑controles, trust score. Op papier klinkt het als een platform. In werkelijkheid is het een lijst met taken, na welke je je laptop wilt sluiten.

Ik besefte dat ik infrastructuur bouwde rond een probleem dat ik nog niet had bewezen.

Ik moest terugkeren naar de saaie vraag: waarom komt een mens überhaupt naar storevi.be? Een project tonen, een project vinden of bepalen of je het project kunt vertrouwen. Alles wat eromheen moet helpen.

Na die heroverweging werd het product eenvoudiger. Niet perfect eenvoudig, maar tenminste stopte het met zich in alle richtingen uit te spreiden.

Tweede fout: AI begon mooie leegte te schrijven

Ik wilde het voor de auteur makkelijk maken om een project toe te voegen. Niet een enorme vorm, maar een gewoon beschrijving. Vibe‑coders werken al zo met AI: ze leggen uit, verduidelijken, kijken naar het resultaat, verduidelijken opnieuw. Een projectkaart moet ongeveer op dezelfde manier beginnen.

Vervolgens zou AI helpen om er een normale kaart van te maken.

Het idee is goed. Maar de eerste versie liet snel een onaangename eigenschap zien: AI houdt ervan overtuigend te schrijven, zelfs als er weinig feiten zijn.

De auteur schrijft iets als: “we maken een platform voor het automatiseren van beslissingen met AI”. AI transformeert dit vrolijk in een nette tekst over een innovatieve aanpak, efficiëntie en schaalbaarheid. Het is prettig om te lezen. De toegevoegde waarde is klein.

En in het product mag je ook geen feiten vervangen door een gladde tekst.

Daarom begon ik de AI‑editor in een andere richting te sturen. Zijn taak is niet “maak het mooi”. Zijn taak is om vervelende verduidelijkende vragen te stellen. Wie is de gebruiker? Waar kun je het product proberen? Wat is er al gedaan, en wat is nog maar een belofte?

Met andere woorden, AI binnen storevi.be is nu eerder een helper‑interviewer. Het markeert gaten, stelt formuleringen voor en vertaalt de kaart automatisch naar de talen van het platform. Dit is belangrijk niet om een mooie vinkje “we hebben lokalisatie” te krijgen, maar om het zoeken en het verlagen van de toetredingsdrempel. De auteur hoeft niet handmatig een versie voor elke taal te maken, en de lezer hoeft niet weg te gaan omdat het project niet in zijn taal is beschreven.

Trust Score bleek gevaarlijker te zijn dan ik dacht

Ik wilde een vertrouwensscore toevoegen. Het lijkt logisch: als het project open is, de auteur is bevestigd, er screenshots zijn, er een geschiedenis is, geen duidelijke problemen, dan is er meer vertrouwen.

Maar zodra een cijfer verschijnt, begint het te veel zelfverzekerd te lijken.

77/110 klinkt solide. Maar een normale lezer zal meteen vragen: waarom 77 en niet 54? Wie heeft het beslist? AI? Auteur? Waarom weegt populariteit zo zwaar, en bevestiging van de auteur zo?

En dat zijn goede vragen.

Daarom wordt de trust score geleidelijk niet een “projectbeoordeling”, maar een set signalen. Beschikbaarheid, uniekheid, auteur bevestiging, activiteit, vooruitzichten. Ik vind het eerlijker – “dit is wat we kunnen verifiëren, en dit is nog leeg”.

Dit deel is nog ruw. Maar de fout zelf was nuttig: als het product over vertrouwen spreekt, mag het niet achter zich verschuilen achter mooie cijfers.

Wat uiteindelijk de kern werd

De kern van storevi.be is nu een projectkaart met context.

Niet zomaar “hier is de link”, maar een korte analyse: wat is het, wie doet het, wat is er al beschikbaar en welke vragen blijven er over het project.

Voor mij is dit niet alleen theorie. Op het platform zijn al een aantal projecten die ik parallel beheer en ontwikkel. Ze zijn verschillend: van een AI‑assistent voor de Aziatische keuken en een service met interactieve panoramische reizen tot een leasingplatform voor kleine bedrijven. Ik houd ze bewust bij elkaar, omdat je er goed kunt zien hoe verschillend het is om het idee, de fase, de risico’s en de voordelen uit te leggen.

Ik heb apart artikelen en discussies toegevoegd. De kaart wordt snel droog, terwijl de lanceringshistorie levend materiaal is.

De gemeenschap van auteurs verscheen later. Niet omdat het "platform een gemeenschap nodig heeft", maar omdat je na het bekijken van een project vaak de neiging hebt om een persoon te schrijven. Niet alleen een like geven, maar vragen stellen of hulp aanbieden.

Wat nog niet werkt

Het is nog niet gelukt om aan te tonen dat het platform op zichzelf nodig is voor een groot aantal auteurs. Er is een werkend product, er is logica, er zijn kaarten, er zijn eerste projecten. Maar dat betekent nog niet dat er een gedragspatroon is gevonden dat mensen constant zullen herhalen.

Het is niet gelukt om de trust score voldoende begrijpelijk te maken. Het is al nuttig als interne richtlijn, maar voor een externe persoon lijkt het nog steeds soms een "enige beoordeling".

Het is niet gelukt om volledig af te zien van het gevoel van een catalogus. De eerste blik leest nog steeds kaarten en het projectrooster. Dus we moeten de geschiedenis en de antwoorden van de auteur sterker laten uitkomen.

En het is nog niet gelukt om het publicatieproces zo eenvoudig te maken als gewenst. AI-interviews helpen als de vragen van de kern van het project komen. Maar de auteur mag niet het gevoel hebben dat hij een sollicitatiegesprek bij de bank doorloopt.

Wat nu

De komende taak is om het vertrouwen in een normale vorm te brengen: wat is geverifieerd, wat niet en waar de risico’s blijven.

Ik wil ook de kaarten en lanceringshistorieën sterker verbinden. Zo wordt het project niet een statische pagina, maar een levendige registratie: wat is veranderd, waar zijn fouten gemaakt, wat is beter geworden. Je kunt al een artikel schrijven over het gepubliceerde project en ze verbinden.

En natuurlijk zijn er auteurs nodig. Zonder mensen is het gewoon een nette demo. Ik ben niet alleen geïnteresseerd in kant-en-klare startups, maar juist in de ruwe fase – prototypes, experimenten en micro‑SaaS die eerlijk erkennen wat ze zijn.

En hier is voor mij opnieuw de internationale context belangrijk. Ik wil niet dat storevi.be een platform is voor slechts één lokale groep. Het product kan nu door iemand in de VS worden gemaakt, getest door mensen uit Duitsland, besproken door Russisch‑sprekende specialisten, en de eerste klanten komen zelfs uit China. Daarom moet de projectkaart begrijpelijk zijn voor niet alleen de "eigenaars", die de auteur al kennen, maar voor mensen met verschillende ervaring, taal en context. Automatische vertaling is hier geen versiering, maar een manier om het project meer kans te geven gevonden te worden via zoekmachines.

Welke hulp is nodig

Als je een klein AI‑product maakt, probeer dan een kaart toe te voegen en kijk welke vragen er opkomen. Het is vooral interessant als het project nog niet perfect is.

Als je een ontwikkelaar bent, heb ik kritiek op de technische logica nodig. Waar zien de controles gevaarlijk uit? Waar kan AI liegen? Waar creëert de trust score valse zekerheid?

Als je een productmanager of marketeer bent, bekijk dan de positionering. Is het duidelijk waarom dit nodig is? Lijkt het niet een ander catalogus? Wat moet er op de kaart staan om je te laten willen schrijven aan de auteur?

Als je gewoon een lezer bent, stel een ongemakkelijke vraag. Alleen, het moet specifiek zijn. Die kritiek is minder aangenaam, maar nuttiger.

Vroeger was het voor velen moeilijk om een product te maken. Nu wordt het steeds moeilijker om uit te leggen waarom men ernaar moet kijken.

Dit is het probleem dat ik probeer op te lossen.