2026: Het Jaar Waarin Coderen Goedkoop Werd en Publiek de Gracht Werd

Je hebt deze blog waarschijnlijk gevonden via linkedin of x

Dat is precies het punt. Ik bouw al jaren weekendprojecten — trading bots, nft-marktplaatsen, ios-apps, garmin watchfaces, e-commerce platformen, taalleerapps. De meeste falen. Sommige blijven plakken. Maar ze maken me allemaal enthousiast

Het probleem? Ik bouwde in stilte. Ik besteedde drie maanden aan een project, lanceerde naar nul gebruikers en ging dan door naar het volgende. Steeds weer opnieuw. De code was er. De producten werkten. Maar niemand wist dat ze bestonden

Wat Veranderde in 2025-2026

Er viel iets op z'n plek toen ik de cijfers zag. 82% van de developers gebruikt nu AI-tools om code te schrijven. Microsoft en Google kondigden aan dat een kwart van hun code door AI gegenereerd is. Cursor ging van nul naar 18% marktaandeel in 18 maanden

Het ding waar ik jaren in geïnvesteerd had — schone, efficiënte code schrijven — werd bijna van de ene dag op de andere een commodity (inwisselbaar goed). Dit is wat ik besefte: de code die ik schrijf doet er minder toe dan de mensen die erom geven. Het concurrentievoordeel — de moat (gracht) — is niet langer technische vaardigheid

Het Onderzoek Dat Me Overtuigde

Ik ben er diep ingedoken. Alles gelezen wat ik kon vinden over AI-coderingstools, indie hacker succesverhalen en de economie van building in public (bouwen in het openbaar). De data was duidelijk:

Code wordt snel een commodity

• Github Copilot: 42% marktaandeel, 20M+ gebruikers
• Open-source alternatieven die dezelfde kwaliteit bieden op gratis tiers
• Prijzenoorlog in aantocht: $20/maand onbeperkt → $0,02-0,05 per verzoek

Maar publiek werd waardevol

• 22% van linkedin-creators verdient significant inkomen via hun aanwezigheid
• Indie hackers met publiek: $57K-79K uit nevenprojecten in 2025
• Building in public toont 7-12x betere conversie dan Product Hunt-lanceringen

De indie hackers die slaagden waren geen betere developers. Ze hadden mensen die hen vertrouwden vóór ze lanceerden. Dat raakte me

Waarom Dit Ertoe Doet voor Weekendbouwers

Ik bouw veel. Het is wat me enthousiast maakt. Het ene weekend bouw ik een trading bot. Het volgende weekend een ios-app. Dan een garmin watchface. Dan een e-commerce platform. Ik kan er niets aan doen. De ideeën blijven maar komen en ik hou ervan ze tot leven te brengen

Maar dit is het patroon dat ik bleef herhalen: drie maanden bouwen → lanceren naar nul gebruikers → krekels horen → door naar het volgende project. De code was goed. De producten werkten. Maar niemand wist dat ze bestonden. Dat was het moment dat ik zag wat er gebeurde met building in public

De Building in Public Beweging

Developers die hun reis delen op x, linkedin, indie hackers. Mislukkingen documenteren. Omzetcijfers tonen. In het openbaar om feedback vragen

Kijk, ik heb normaal een hekel aan al dat indie hacker-jargon. Iedereen doet alsof ze iets nieuws ontdekken, probeert je te lokken met gidsen over „hoe ik $10k MRR maakte in 30 dagen" terwijl de meeste van die apps geen echt geld genereren. Maar de terminologie is overal, dus hier is wat het echt betekent: MRR is monthly recurring revenue (maandelijks terugkerende inkomsten), moat is je concurrentievoordeel (gracht), building in public is je reis delen terwijl je bouwt, indie hackers zijn solofounders, en de grind is gewoon consistent opdagen. Niets hiervan garandeert succes. De meeste projecten falen nog steeds. De enige reden dat sommige van deze projecten echt slagen is omdat hun makers een enorme following hebben

Eén founder bouwde een simpele database GUI-tool. Niets revolutionairs. Maar hij had 15.000 volgers door jarenlang database-concepten uit te leggen op twitter. Lanceerde naar $8k in de eerste maand. Niet omdat het product beter was. Omdat mensen hem vertrouwden en zijn werk wilden steunen. Ondertussen lanceerden technisch superieure producten met nul publiek naar krekels

Dus Nu Documenteer Ik Alles

Dit is wat ik besloot te doen. Elk weekendproject wordt gedocumenteerd. Elke mislukking wordt gedeeld. Elke les die ik leer komt in een blogpost. Trading bots, ios-apps, web3-experimenten, AI-integraties — alles. Niet omdat ik denk dat mijn projecten speciaal zijn. Omdat ik het enige bezit aan het opbouwen ben dat er echt toe doet in 2026: een publiek dat me vertrouwt

De Verschuiving in Aanpak

Oude aanpak:

Nieuwe aanpak:

De codekwaliteit is hetzelfde. De producten zijn hetzelfde. Maar de uitkomsten zijn compleet anders. (trouwens, de diagrammen hierboven zijn mermaid charts — gegenereerd met claude code)

Waarom Weekendprojecten Perfect Hiervoor Zijn

Als je bent zoals ik — constant nieuwe projecten starten omdat je van bouwen houdt — dan werkt deze aanpak misschien zelfs beter. De meeste adviezen zeggen „kies één ding en ga er jarenlang diep op in." Maar zo werk ik niet. Ik word enthousiast over nieuwe ideeën. Ik wil verschillende technologieën uitproberen. Ik hou van variatie

Als ik een nieuw garmin watchface aan het bouwen ben of aan het experimenteren met een crypto tradingstrategie, ben ik oprecht nieuwsgierig of het gaat werken. Die energie is echt. En mensen voelen dat. Building in public maakt daar een bezit van. Elk weekendproject wordt content. Elke koerswijziging wordt een les. Elke mislukking wordt een verhaal. Het portfolio van gedocumenteerde experimenten is misschien meer waard dan één succesvol product. Dat is in ieder geval de gok die ik neem

Waarom Jij Dit Misschien Wilt Proberen

Kijk, ik weet niet of dit op de lange termijn voor mij gaat werken. Misschien bouw ik een publiek op van 10.000 mensen en lanceer ik producten naar warme leads. Misschien heb ik 47 volgers en voel ik me een idioot dat ik alles publiekelijk deelde. Maar dit weet ik zeker: de oude aanpak werkte niet. Maandenlang in stilte bouwen. Lanceren naar krekels. Ik vroeg me af waarom niemand gaf om het ding waar ik mijn hart en ziel in had gestopt. Dat patroon moest doorbroken worden

Waar Ik Op Wed

De these is simpel: in een wereld waar AI code kan schrijven, is het onderscheidende vermogen weten wát je moet bouwen en wie het nodig heeft. Building in public helpt bij beide. weten wat je moet bouwen: als je je ideeën vroeg deelt, vertellen mensen je of het dom is. Bespaart maanden aan het bouwen van het verkeerde. vinden wie het nodig heeft: als je je reis documenteert, vinden mensen die dezelfde problemen hebben je vanzelf. Zij zijn je early adopters

De vaardigheden die er nu toe doen:

• gebruikersbehoeften begrijpen (praat met mensen)
• goede architecturale beslissingen nemen (kun je nog niet aan AI delegeren)
• vertrouwen en relaties opbouwen (de echte gracht)
• communiceren wat je bouwt en waarom (distributie)

Pure codeervaardigheden? Gecommoditiseerd. Het vermogen om code te shippen terwijl je een publiek opbouwt? Dat is misschien de nieuwe zeldzame vaardigheid

Het Experiment Gaat Verder

Deze blog is onderdeel van het experiment. Elk weekendproject dat ik bouw wordt hier gedocumenteerd. Elke mislukking wordt gedeeld. Elke technische beslissing wordt uitgelegd. Misschien leidt dit ergens toe. Misschien niet. Maar dit weet ik: het slechtste geval is dat ik een portfolio heb van gedocumenteerd werk dat laat zien wat ik kan. Het beste geval is dat ik een publiek opbouw dat echt geeft om wat ik bouw. Beide uitkomsten zijn beter dan in stilte bouwen en je afvragen waarom niemand weet dat je projecten bestaan