Wat gebeurt er als je de rollen omdraait? Niet "wat kan AI voor mij doen?", maar "dit zijn de harde grenzen, wat kan ik er binnen bouwen?". Ik besloot een experiment aan te gaan met twee strakke constraints: maximaal $100 aan AI-tokens en 40 uur werk. Het doel: een volledig functionerend product neerzetten, puur door te prompten. Het resultaat is here-we-go.com, en de belangrijkste lessen gingen niet over code, maar over architectuur, concurrency en de onverwachte kosten van succes.
Door: Frank Timmermans
Na een reeks kleinere, handige tools te hebben gebouwd – van workflow-optimizers voor werk tot appjes voor mijn dochter – vond ik het tijd voor een meer gestructureerd experiment. De inzet was niet om een unicorn-startup te bouwen of te bewijzen dat AI productteams kan vervangen. Het doel was veel pragmatischer: hands-on ervaring opdoen en leren waar AI echt helpt, en waar de grenzen liggen als je budget en tijd beperkt zijn en 'prompting' je primaire gereedschap is.
Enkele technische en functionele highlights:
1. Prompting = Architectuur AI schrijft de code, maar als bouwer moet je strikt de systeemarchitectuur, de logica achter edge-cases en de UX beheren. Zonder een strak technisch plan verzand je snel in een ononderhoudbare brij van code.
2. De 80/20 regel blijft gelden Werkende code genereren is de 'makkelijke' 80%. De resterende 20% van de tijd (en vaak de meeste moeite) gaat zitten in het 'echte' ambacht: GitHub-workflows inrichten, Supabase RLS (Row Level Security) regels aanscherpen, privacyverklaringen en GDPR-compliance opstellen, de admin-interface ontwerpen en hardnekkige bugs platslaan.
3. Zelfvertrouwen is geen correctheid Een AI kan een fout antwoord net zo vloeiend en overtuigend uitleggen als een juist antwoord. De belangrijkste vaardigheid is niet 'beter prompten', maar sceptisch genoeg blijven om claims te verifiëren in plaats van ze klakkeloos te accepteren.
4. Bugs herhalen zich in patronen Dezelfde grondoorzaak (bijvoorbeeld een waarde die werd gedupliceerd in plaats van één keer geteld) bleef opduiken in verschillende gedaanten. Alleen de symptomen bestrijden is niet genoeg; je moet het patroon opsporen en overal elimineren.
5. Veiligheid zit in de saaie leidingen De risicovolste bugs zaten niet in de features of de UI, maar in toegangsregels (RLS) die onzichtbaar zijn bij normaal gebruik. Een fix op de ene plek kan onbedoeld de beveiliging elders openbreken.
6. Harde grenzen versnellen het leren Een vast budget en tijdskader dwongen me tot pragmatische beslissingen en legden genadeloos zowel de sterke punten als de beperkingen van AI-ondersteunde ontwikkeling bloot.
Aannames: ~0.5MB DB per gebruiker, WAU≈MAU, ~8MB egress/maand, ~0.3 e-mails/gebruiker/maand.
De schokkende ontdekking: Bij 1 miljoen gebruikers bestaat ruwweg twee-derde van de gehele factuur uit één enkele post: Supabase's Auth billing. Niet de database, niet de bandbreedte, niet de compute.
Database-opslag blijft onder de 500GB, zelfs bij 1M gebruikers. Dat is een afrondingsfout, geen risico. Opslag en bandbreedte groeien lineair en voorspelbaar. Auth niet. Na de gratis tier wordt elke extra actieve gebruiker individueel gefactureerd, zonder volumekorting.
Het echte risico is niet de kostenpost die je trackt, maar de post waarvan je aannam dat die gratis was. Auth voelt 'opgelost' totdat het de grootste post op de factuur is, precies op het moment dat je product succesvol begint te worden.
De Workaround-val: Ik heb gekeken of het switchen van auth-provider (zoals Clerk, Auth0, Firebase Auth) zou helpen. Supabase ondersteunt dit officieel. Maar wat blijkt? Supabase heeft in hun release notes expliciet vermeld dat ze de prijzen voor third-party auth gelijk hebben getrokken met hun eigen tarieven: dezelfde $0.00325/MAU, maar dan met het label "Third-Party MAU". De ontsnappingsroute was bewust al afgesloten. De enige echte oplossing is een architecturale rewrite, geen simpele instelling die je omzet.
Voor een asynchrone reis-app als here-we-go.com is de kans op massale simultane pieken gelukkig laag. In tegenstelling tot ticketing-platforms gebeurt het loggen van reizen asynchroon; zelden zijn meer dan 0.5% tot 1% van de MAU actief in exact dezelfde minuut.
Als je een side-project of MVP bouwt met AI, ontwerp dan je data- en auth-architectuur voordat je de schaal raakt. De tools maken het moeiteloos om van 0 naar 1 te gaan, maar levensvatbaar blijven van 1 naar 1.000.000 is nog steeds puur menselijk ingenieursvakmanschap.
Door: Frank Timmermans
Na een reeks kleinere, handige tools te hebben gebouwd – van workflow-optimizers voor werk tot appjes voor mijn dochter – vond ik het tijd voor een meer gestructureerd experiment. De inzet was niet om een unicorn-startup te bouwen of te bewijzen dat AI productteams kan vervangen. Het doel was veel pragmatischer: hands-on ervaring opdoen en leren waar AI echt helpt, en waar de grenzen liggen als je budget en tijd beperkt zijn en 'prompting' je primaire gereedschap is.
Het Resultaat: here-we-go.com
Wat is het geworden? Een intuïtief platform voor het loggen van reizen, ontworpen om je trips moeiteloos bij te houden, te visualiseren en te delen. In plaats van rommelige spreadsheets of verspreide fotoalbums, verandert het je reizen in interactieve, visuele tijdlijnen op een moderne dashboard.Enkele technische en functionele highlights:
- Volledige Data-eigendom: Gebruikers kunnen hun tripdata op elk moment exporteren (CSV/Excel of JSON) of hun account met één klik verwijderen.
- Privacy by Design: Het platform is 100% gratis, heeft nul tracking en verzamelt geen statistieken. Profielen zijn standaard privé.
- Self-Service Admin: Een op maat gemaakte admin-interface om gebruikers en uitnodigingen te beheren en site-copy aan te passen – allemaal zonder code aan te raken.
De Investering
De harde grenzen die ik stelde, resulteerden in deze uiteindelijke kostenposten:- $98 (eenmalig): AI-tokens (o.a. Claude/OpenAI via API).
- $14 / jaar: Domeinnaam.
- $23 / maand: Supabase Pro (Database, Auth, Storage & Edge Functions).
- 40 Uur: Prompten, itereren, bugfixing en bijsturen.
Belangrijkste Leerpunten: Prompting is Architectuur
Het bouwen zelf met AI-ondersteuning gaat razendsnel, maar de echte uitdagingen liggen elders.1. Prompting = Architectuur AI schrijft de code, maar als bouwer moet je strikt de systeemarchitectuur, de logica achter edge-cases en de UX beheren. Zonder een strak technisch plan verzand je snel in een ononderhoudbare brij van code.
2. De 80/20 regel blijft gelden Werkende code genereren is de 'makkelijke' 80%. De resterende 20% van de tijd (en vaak de meeste moeite) gaat zitten in het 'echte' ambacht: GitHub-workflows inrichten, Supabase RLS (Row Level Security) regels aanscherpen, privacyverklaringen en GDPR-compliance opstellen, de admin-interface ontwerpen en hardnekkige bugs platslaan.
3. Zelfvertrouwen is geen correctheid Een AI kan een fout antwoord net zo vloeiend en overtuigend uitleggen als een juist antwoord. De belangrijkste vaardigheid is niet 'beter prompten', maar sceptisch genoeg blijven om claims te verifiëren in plaats van ze klakkeloos te accepteren.
4. Bugs herhalen zich in patronen Dezelfde grondoorzaak (bijvoorbeeld een waarde die werd gedupliceerd in plaats van één keer geteld) bleef opduiken in verschillende gedaanten. Alleen de symptomen bestrijden is niet genoeg; je moet het patroon opsporen en overal elimineren.
5. Veiligheid zit in de saaie leidingen De risicovolste bugs zaten niet in de features of de UI, maar in toegangsregels (RLS) die onzichtbaar zijn bij normaal gebruik. Een fix op de ene plek kan onbedoeld de beveiliging elders openbreken.
6. Harde grenzen versnellen het leren Een vast budget en tijdskader dwongen me tot pragmatische beslissingen en legden genadeloos zowel de sterke punten als de beperkingen van AI-ondersteunde ontwikkeling bloot.
De Verborgen Kosten van Schaalbaarheid
Het project leerde me nog iets anders, wat een eigen sectie verdient: wat kost dit geintje eigenlijk als het succesvol wordt? Ik heb de stack van HereWeGo (Supabase, Netlify, Resend) doorgerekend voor drie groeistadia, gebaseerd op de tarieven van 2026:| Schaal | Maandelijkse Kosten (Schatting) |
| 10.000 gebruikers | ~$37 |
| 100.000 gebruikers | ~$202 |
| 1.000.000 gebruikers | ~$4.604 |
De schokkende ontdekking: Bij 1 miljoen gebruikers bestaat ruwweg twee-derde van de gehele factuur uit één enkele post: Supabase's Auth billing. Niet de database, niet de bandbreedte, niet de compute.
Database-opslag blijft onder de 500GB, zelfs bij 1M gebruikers. Dat is een afrondingsfout, geen risico. Opslag en bandbreedte groeien lineair en voorspelbaar. Auth niet. Na de gratis tier wordt elke extra actieve gebruiker individueel gefactureerd, zonder volumekorting.
Het echte risico is niet de kostenpost die je trackt, maar de post waarvan je aannam dat die gratis was. Auth voelt 'opgelost' totdat het de grootste post op de factuur is, precies op het moment dat je product succesvol begint te worden.
De Workaround-val: Ik heb gekeken of het switchen van auth-provider (zoals Clerk, Auth0, Firebase Auth) zou helpen. Supabase ondersteunt dit officieel. Maar wat blijkt? Supabase heeft in hun release notes expliciet vermeld dat ze de prijzen voor third-party auth gelijk hebben getrokken met hun eigen tarieven: dezelfde $0.00325/MAU, maar dan met het label "Third-Party MAU". De ontsnappingsroute was bewust al afgesloten. De enige echte oplossing is een architecturale rewrite, geen simpele instelling die je omzet.
De Ontbrekende Dimensie: Concurrency & Piekbelasting
Na de initiële analyse realiseerde ik me dat ik een cruciale dimensie miste: concurrency. Schalen gaat niet alleen over het totaal aantal geregistreerde accounts (MAU), maar over wat er gebeurt als een fractie van die gebruikers tegelijkertijd de app raakt. Piekverkeer verschuift de bottleneck van MAU-facturatie naar databaseverbindingen, compute en I/O-limieten.Voor een asynchrone reis-app als here-we-go.com is de kans op massale simultane pieken gelukkig laag. In tegenstelling tot ticketing-platforms gebeurt het loggen van reizen asynchroon; zelden zijn meer dan 0.5% tot 1% van de MAU actief in exact dezelfde minuut.
- 100 Gelijktijdige Gebruikers (~10k–20k MAU): Moeiteloos afgehandeld door een basis Supabase Pro-plan ($25/maand) via standaard connection pooling. Kostenimpact: +$0–$10/maand.
- 1.000 Gelijktijdige Gebruikers (~100k MAU): Simpele queries draaien prima mits geïndexeerd, maar verbindingslimieten en edge-executies vereisen dedicated database compute add-ons. Kostenimpact: +$60–$200/maand.
- 10.000 Gelijktijdige Gebruikers (~1M MAU / Viraal Event): Vereist upgrades naar hogere database compute-tiers, dedicated read-replicas, een externe Redis-cachinglaag en high-bandwidth egress om crashes te voorkomen. Kostenimpact: +$800–$2,500+/maand.
Conclusie: Schaal Bewust
Het stellen van harde grenzen heeft me laten zien dat bouwen met AI opmerkelijk snel gaat, maar dat schalen fundamenteel architecturaal bewustzijn vereist. De grootste bedreiging voor een indie-product is niet of AI de code kan schrijven, maar de verborgen prijsvalstrikken en concurrency-bottlenecks in de third-party services die je gebruikt.Als je een side-project of MVP bouwt met AI, ontwerp dan je data- en auth-architectuur voordat je de schaal raakt. De tools maken het moeiteloos om van 0 naar 1 te gaan, maar levensvatbaar blijven van 1 naar 1.000.000 is nog steeds puur menselijk ingenieursvakmanschap.
:strip_icc():strip_exif()/u/17313/_IGP1526kl2.jpg?f=community)