Hoe we Plens bouwden, van idee tot app

Wat is Plens?

Plens is een app die zegt wanneer je het droogst vertrekt. Je geeft je route op en hoeveel eerder of later je kunt vertrekken, en Plens rekent langs de hele route uit waar de regen is op het moment dat jij er langskomt. De webversie en de links naar de app staan op plensapp.nl⁠↗.

De vraag waar het product om draait, staat bovenaan de README van de webrepo: als ik rond mijn gewone tijd van A naar B fiets, wanneer kan ik dan het beste vertrekken om onderweg zo min mogelijk regen te krijgen? Fietsen was het begin. Inmiddels werkt Plens ook voor hardlopen en wandelen, en er is de Plensradar: de buien boven Nederland en België, en per vijf minuten of het de komende twee uur op jouw plek regent. De radar en het vertrekadvies werken zonder account.

Plens is een van de producten van Studio Northstar. De stand van zaken staat op de productpagina van Plens. Dit artikel gaat over hoe het gebouwd is. De techniek zelf, van KNMI-radar tot adreszoeker, staat in de techniek achter Plens.

Welk probleem lost Plens op?

Een weerbericht gaat over één plek en één uur, je rit over twintig plekken in twintig minuten. Plens kijkt per stuk van je route naar de regen op het moment dat jij daar bent, dus een bui die alleen het laatste stuk raakt, telt ook mee.

Uurdata is daarvoor te grof. Een bui van tien over acht tot half negen verdwijnt in een uurgemiddelde, en juist die bui bepaalt of je droog op je werk komt. Daarom rekent Plens met de radarverwachting van het KNMI, in stappen van vijf minuten op een raster van een kilometer.

De maatstaf voor succes is volgens dezelfde README dat je de app niet opent. Je telefoon zegt uit zichzelf “ga tien minuten eerder” en je weet genoeg. Meldingen komen standaard alleen als het advies verandert. En soms is elk vertrek nat. Dan zegt Plens dat ook: “Regen is niet te vermijden” zat in de testbuild van 10 oktober.

Hoe begonnen we?

We begonnen bij de databron, niet bij het scherm. Hoe ver de radar vooruit kan kijken, bepaalt welk vertrekadvies Plens kan geven, en dat werd de scope.

De KNMI-radarverwachting kijkt twee uur vooruit. Dat is genoeg voor een woon-werkrit en te kort voor een dagplanning. Het eerste half uur is het nauwkeurigst, daarna wordt de verwachting grover. Het rekenmodel noemt de betrouwbaarheid hoog tot 35 minuten aanlooptijd, gemiddeld tot twee uur en daarna laag, en verwijst daarvoor naar verificatiestudies van radarverwachtingen boven Nederland. Plens zegt daarom bij elk advies hoe zeker het is.

Ook de keuze van bronnen begon als onderzoek. In augustus 2026 legde het team per bron vast wat technisch kon en wat juridisch mocht, en de licentie gaf vaak de doorslag. De KNMI-radar valt onder CC BY 4.0 en mag commercieel gebruikt worden. Een andere radarbron stond alleen open voor persoonlijk en educatief gebruik en viel af. Bij routeplanners was de vraag of je een route mag bewaren. Een woon-werkroute verandert zelden, dus je wilt hem één keer plannen en daarna hergebruiken, en veel aanbieders verbieden precies dat.

Zo beginnen we elk product: eerst onderzoek naar wat het moet opleveren en waar de grenzen liggen, dan pas bouwen.

Hoe bouwden we het met agents?

Plens is gebouwd door één bouwer met meerdere AI-agents naast elkaar. Vrijwel alle commits in beide repo's staan op naam van Alan Abdulla, mede-oprichter van Studio Northstar, die werkte met Claude Code, Codex en Cursor. Niels Vermaat heeft twaalf commits in de webrepo. Melle Doreleijers beslist over privacy en over de publieke release.

De tijdlijn

Van de eerste webcommit tot de testbuild van 10 oktober zaten ongeveer zes weken. Van de eerste appcommit tot de gesloten Play-test elf dagen.

De omvang

Stand 11 oktober 2026: de webrepo telt 1.286 commits en 604 gemergde pull requests, de app-repo 684 commits en 202 gemergde pull requests. In de app-repo dragen 397 van de 684 commits een Co-Authored-By-regel van Claude. Die getallen zeggen iets over tempo, niet over kwaliteit. Een commit kan een komma zijn of een hele functie.

De app kwam er niet zomaar bij. In het architectuurbesluit van 21 september zijn vier opties gewogen op onder meer onderhoud door een klein team, push en deep links, en storekwaliteit. Expo en React Native scoorden 157 punten, twee volledig native apps 106, een webwrapper 104 en alleen een web-app 92. Het besluit legt ook grenzen vast, zoals geen providersleutel of ander geheim in de appbundel.

Wie deed wat

Elke agent had zijn eigen soort werk. Volgens de roadmap zette Cursor de eerste opzet neer. Codex deed het pariteitsregister, het architectuurbesluit, de Android-widgets en de storerecords. Claude Code bouwde de mobiele API, het native fundament, pushmeldingen, betalen in de app en het compliancewerk.

Er liepen sessies tegelijk, in de cloud en op de Mac. Om botsingen te voorkomen meldt elke sessie zijn branch aan op een werkbord. Dat bord toont ook welke bestanden in meer dan één open branch veranderen, met als omschrijving “een mergeconflict in wording”. Cloudsessies draaien zonder secrets. Een iOS-simulator, EAS-builds en storepublicatie kunnen daar niet, dus dat werk gaat naar de Mac.

Elke wijziging begint met een productwijzigingsrecord: een klein JSON-bestand dat vastlegt wat er verandert en waarom. Dan maakt het niet uit welke sessie de wijziging oppakt. De app bewaart daarnaast de commit, de manifesthash en de OpenAPI-hash van de webkern. Lopen web en app uit elkaar, dan faalt de CI.

Eerst reviewen, dan bouwen

De opdracht aan Claude Code begon niet met bouwen maar met reviewen: eerst kritisch kijken naar wat Codex al had gebouwd, daarna verbeteren in “kleine, aantoonbare verticale bouwlussen”. Op 24 september las een onafhankelijke review de app door, met aparte agents die alleen mochten lezen. De eerste blokkerende bevinding was dat de hele app in één bestand van 317 regels zat, zonder deep links. Dezelfde dag volgden dertien bouwlussen, van het fundament tot Pro kopen in de app.

Ons eigen platform ARCS zette Plens selectief in. De startopdracht zegt dat de controles van ARCS alleen gebruikt worden waar ze een concreet besluit of kwaliteitsbewijs verbeteren.

Aan het eind van de keten bouwt Claude ook zelf: builds maken, indienen bij Apple en Google en testnotities zetten, telkens pas na Alans go. Op 10 oktober publiceerde Claude de door Google goedgekeurde Android-build voor de gesloten test.

Wat ging er mis en wat leerden we?

Het meeste ging mis buiten de code: bij builds, stores en het verschil tussen een geslaagde build en een app die op een telefoon werkt. Het team schreef de lessen zelf op in de overdrachtsdocumenten. Zes ervan:

1. Nieuwe iOS-rechten breken de build. Toen inloggen met Apple en Associated Domains erbij kwamen, faalde de EAS-build tot Alan één interactieve build draaide met zijn eigen Apple-login. Nu wordt app.json vóór een build nagekeken en wordt zo'n wijziging vooraf gemeld.
2. Een env-wijziging in Vercel geldt pas na een deploy. Claude deployt niet zelf naar productie. Een kleine merge in de webrepo laat de deploy lopen, in plaats van dat Alan met de hand opnieuw deployt.
3. Productrecords zijn append-only. Wat vastligt, pas je niet aan. Je voegt een nieuw record toe, zodat te volgen blijft wie wat besloot.
4. Een native build gebruikt nooit voorbeelddata. Registreren op de Android-emulator maakte op 5 oktober per ongeluk een echt account aan.
5. Open geen andere Play-edits tijdens een indiening. De Android-indiening van versie 0.14.0 liep vast omdat een eigen controlelus elke 30 seconden een Play-edit opende, waardoor de edit van de indiening verliep. De build ging daarna rechtstreeks via de API van Google Play.
6. Een claim is geen bewijs. In de documentatie stond dat Siri op de Apple Watch zou werken. Dat bleek onjuist. De Watch-app is bewust nog niet gebouwd, besloot Alan op 28 september.

De rode draad is bewijs. De startopdracht zegt het letterlijk: “Claim geen toestelbewijs op basis van een succesvolle bundel of EAS-build.” Dat een build slaagt, zegt nog niet dat de app op een telefoon doet wat hij moet doen. Daarom staat elke functie in een pariteitsregister, per platform, en telt hij pas als hij op een echt toestel is bewezen.

Waar staat Plens nu?

Plens is beschikbaar. De webversie draait op plensapp.nl⁠↗, en de app staat sinds 10 oktober op versie 0.16.3 bij testers: op iOS in TestFlight, op Android in een gesloten test die Google heeft goedgekeurd. Een versie 1.0 is er bewust nog niet. Op 9 oktober besloot Alan eerst de feedback uit TestFlight te verwerken.

Publiek gaat de app pas als alle regels in het pariteitsregister op iOS én Android bewezen zijn en Melle akkoord geeft. Op 30 september gaf de releasecheck 106 open voorwaarden: 49 productregels maal twee platforms, plus acht releasevoorwaarden. Het releasedocument zegt er zelf bij dat dat geen lijst van 106 afzonderlijke bugs is.

Plens is gratis te gebruiken; Plens Pro voegt onder meer hardlopen, wandelen en meer routes toe (prijzen op plensapp.nl⁠↗). De volgende mijlpaal op onze productpagina is een pilot met forenzen. Daarna volgt beheer: we brengen onze eigen producten zelf op de markt en zien zo hoe ze het in dagelijks gebruik doen.

Is Plens de enige app die dit doet?

Nee. Er bestaan al Nederlandse apps die regenadvies voor je route geven, met een melding erbij. Het team schreef dat zelf op in de README, onder de kop over waarin Plens zich onderscheidt:

Wat Plens doet, is rekenen met de KNMI-radarverwachting in stappen van vijf minuten op een kilometer, per stuk route op het moment dat jij er bent, en bij elk advies zeggen hoe zeker het is. Of dat voor jouw ritten verschil maakt, merk je het snelst door het een week naast je eigen gewoonte te gebruiken.

Wat neem je mee als je zelf een app wilt bouwen?

Een app bouwen met AI gaat snel als vastligt wat je bouwt en hoe je bewijst dat het werkt. Drie dingen uit Plens zien we in elk project terug.

• Begin bij de beperking. De radar bepaalde wat Plens kan beloven. Wie eerst schermen ontwerpt, ontdekt die grens pas later.
• Leg besluiten vast waar agents ze lezen. Een architectuurbesluit, productrecords en een werkbord zorgen dat de ene sessie weet wat de andere deed.
• Scheid bouwen van bewijzen. Een geslaagde build is geen werkende app. Toestelbewijs per platform en een onafhankelijke review horen in het proces, niet erna.

Wil je een app laten bouwen op deze manier, lees dan hoe we agentic engineering aanpakken, of neem contact op.

Plens zelf proberen kan zonder account: de Plensradar en het vertrekadvies staan op plensapp.nl⁠↗.