---
title: "Twee weken agentic coding in een paywalled SaaS-categorie"
date: 2026-05-06T18:18:00.000Z
updated: 2026-05-06T18:18:49.788Z
canonical: https://ninokroesen.nl/blog/twee-weken-agentic-coding-in-een-paywalled-saas-categorie
lang: nl
author: "Nino Kroesen"
---

# Twee weken agentic coding in een paywalled SaaS-categorie

[Hourly](/hourly) is vandaag, 6 mei 2026, live gegaan in de Mac App Store, naast de directe download vanaf deze site. Hij is gratis, draait volledig op je Mac, vraagt niet om een account, en heeft geen paywall achter een van zijn features. Ik heb hem in ongeveer twee weken gebouwd. Voor deze had ik in acht jaar niets meer geshipped naar een Apple-platform.

De hypothese die ik met de lancering wil testen is simpel. Elke gevestigde speler in de menubalk-tijdregistratie-categorie — WorkingHours, Toggl, Timery — zit achter een paywall in een of andere vorm. De reden dat een categorie als deze vandaag verdedigbaar is, is niet dat de software moeilijk te schrijven is; het is dat de kosten van het schrijven en onderhouden ervan hoog genoeg zijn dat wie hem heeft er ook geld voor kan vragen. Generatieve-AI-tooling heeft die kostenstructuur sneller veranderd dan de SaaS-verdienmodellen die bovenop die categorieën draaien hebben kunnen reageren. Hourly is de goedkoopste empirische test die ik kon draaien op de vraag of die verandering daadwerkelijk is aangekomen voor een kleine Mac-app, of dat hij nog verder weg ligt dan hij van binnenuit lijkt.

Ik heb over dit kader geschreven in [de introductiepost](/blog/introduction) toen het project nog op een roadmap stond. Dit is de empirische opvolger daarvan.

## De vorm

Hourly is een menubalk-tijdregistratie voor macOS. Je start een timer voor een project, de seconden tikken in de menubalk weg, je stopt hem. Eerdere entries worden opgesomd en zijn bewerkbaar. Date-range filters en CSV-export zitten erin. Facturatie is multi-currency. Er is een Pomodoro-modus met break overlays en configureerbare werkherinneringen. Calendar export naar Google Calendar en Apple Calendar. Vijf UI-talen — Engels, Nederlands, Duits, Spaans, Frans. Launch-at-login.

Opslag is lokaal. Alles staat in één JSON-file onder `~/Library/Application Support/Hourly/`. Geen account, geen sync, geen serverzijde, niets verlaat je Mac tenzij je het expliciet exporteert. Nul runtime-dependencies in de build zelf; de enige frameworks die worden aangeroepen zijn die van Apple zelf.

Die feature surface is geen toeval, en de volgende sectie gaat over hoe hij gekozen is.

## Hoe de feature surface gekozen is

Voordat ik de build aan het scopen was, ben ik door wat er daadwerkelijk achter de paywalls zat in de vergelijkbare apps in de Mac App Store gegaan. De Pomodoro-modus, de break overlays, de werkherinnering-pings, de calendar export — dat zijn allemaal features die ik in de betaalde apps zag worden ingezet als premium-tier lokkertjes. Het zijn geen features die ik op een vibes-driven feature list van "wat heeft een tijdregistratie nodig" had geprioriteerd. Het zijn features die ik erin heb gescoped omdat de probe een eerlijke test moet zijn. "Gratis tijdregistratie die minder doet dan de betaalde" is een andere bet dan "gratis tijdregistratie die op feature surface gelijk staat aan de betaalde." De bet die ik daadwerkelijk wil draaien is de tweede.

Dat onderzoek is ook de reden dat de app klein is. De laatst gepackagede build is 5,4 MB op disk. De concurrent-groottes die ik heb gecheckt — WorkingHours op 18,1 MB, Toggl op 16,2 MB, Timery op 98 MB — liggen hoger. Een deel van die kloof komt doordat de concurrenten hun account/sync-infrastructuur aan de clientkant meedragen en Hourly niet. Een deel ervan is dat er geen third-party Swift-dependencies in de build zitten. Hoe dan ook, de grootte is onderdeel van de lean-build bet, en het is een van de dingen waar ik op ga letten zodra installaties beginnen op te duiken in de App Store-rapportages.

## Hoe ik bij een Mac-build zonder Xcode terechtkwam

Dit is het deel van de build waar ik vooraf geen prior op had. Ik werk op een MacBook Air, ik zit op dit moment krap in mijn schijfruimte, en het vooruitzicht om de volledige Xcode-bundle te installeren om een kleine Swift-app te compileren was onaantrekkelijk. Ik had het gedaan als het had gemoeten, maar ik had het niet leuk gevonden.

De agentic coding tools waar ik tijdens de build op leunde, stelden een alternatief voor waarvan ik niet wist dat het haalbaar was: een Swift Package plus een paar honderd regels shellscripts, met alleen de Command Line Tools geïnstalleerd. Geen Xcode. Geen simulator. Geen Interface Builder. `swift build` en `swift test` vanuit de terminal, de rest is shell die `codesign` en `notarytool` aan elkaar knoopt. De dev-loop draait vanuit een teksteditor.

Het kostte wat debugwerk om het werkend te krijgen. Apple's tooling neemt op een paar plekken aan dat je in Xcode zit zonder dat te documenteren, en de test target moest het Command Line Tools framework-pad expliciet pinnen zodat `swift test` XCTest überhaupt kon vinden. Maar zodra het was bedraad, draait het hele ding — build, test, sign, notarize, package — end-to-end vanuit de terminal op een machine die nog nooit Xcode op zich heeft gehad. Die toolchain is het ding dat ik meeneem naar elk toekomstig Mac-project dat ik begin. Op een laptop die krap in zijn geheugen zit was hij de unlock die het bouwen van deze app op deze hardware überhaupt haalbaar maakte.

Ik was op eigen kracht niet bij die toolchain uitgekomen. Ik had gemopperd en Xcode geïnstalleerd. Het feit dat een agentic coding tool de no-Xcode-flow als eersteklas optie naar boven bracht is het soort ding dat niet opduikt in de headline-benchmarks van "heeft het model de code goed geschreven" maar wel opduikt in de daadwerkelijke productiviteit van een build als deze.

## De dual-ship was een midden-build-beslissing

Het oorspronkelijke plan was alleen directe download. Geen Apple Developer-account, geen $99 per jaar, geen App Store-reviewproces. Ik zou notarizen via Developer ID, de `.zip` op deze site hosten, en het daarbij laten.

Dat heb ik halverwege de build veranderd. De these die de lancering bedoeld is te testen, is of een gratis lokale app de naald kan verzetten in een categorie waar de gevestigde spelers in de Mac App Store leven. De App Store mijden zou hebben betekend dat de vergelijking plaatsvond op een surface waar de concurrenten niet zaten. Dus heb ik de $99 betaald, een Apple Developer-account geregistreerd, de App Store Connect-kant opgezet, en een tweede packaging-script naast het bestaande directe-download-script gezet. Dezelfde source, twee output-paden. De repository ship't nu vanuit hetzelfde Swift Package naar beide surfaces.

De directe download blijft in de lancering, en niet als dev-artefact of als fallback. App Store-installatie vereist een Apple ID; directe download niet. Er is een echte privacybewuste gebruiker — en een gebruiker op een account-loze machine — voor wie dat onderscheid uitmaakt. Dat pad had ik sowieso geshipped. De App Store is de toevoeging, niet de ruggengraat.

## Wat de review van Apple eruit haalde

Drie reviewrondes voordat hij werd goedgekeurd. Apple steekt echt moeite in het reviewen van apps, en daar mag ik ze van harte voor prijzen ook al zaten er afwijzingen in.

De eerste afwijzing was een echte. De build die ik had ingestuurd crashte bij opstarten op de machine van de reviewer, op een plek waar ik hem op de mijne niet had zien crashen. Het bewijs zat in de crash log:

```
_assertionFailure
static NSBundle.module.getter
AppStrings.bundle(for:)
PomodoroNotifier.requestAuthorizationIfNeeded()
AppModel.init
HourlyApp.init
```

`Bundle.module` is het Swift-package-mechanisme om bij runtime de resource bundle van een package te bereiken. Hij heeft een eenmalige lazy init die fataal foutgaat als hij de bundle niet kan vinden. Op een verse App Store-installatie kon hij hem niet vinden. Op `swift run` lokaal wel. De reden was een packaging-mismatch tussen wat `swift build -c release` produceert en wat Apple's signing-and-thinning pipeline accepteert: Swift Package Manager produceert een geneste resource bundle, en Apple's pipeline behandelt geneste resource bundles inconsistent genoeg dat de binnenste bij runtime niet betrouwbaar terug te laden is. Een vlakke layout — wat elke Mac-app al decennia ship't — overleeft de pipeline ongedeerd.

De fix was vier regels in het packaging-script die de SwiftPM-vormige resource bundle voor het code signen vlak in de `Contents/Resources/` van de app gooien. De bijbehorende verandering staat aan de leeskant: de bundle resolver probeert nu eerst de vlakke layout, en valt alleen terug op de geneste layout als de app onder `swift run` draait. Die divergentie tussen dev en ship is precies het soort ding dat ik lokaal niet had opgevangen, want de lokale pipeline is precies degene die de fout verbergt. De reviewer van Apple ving hem op omdat de reviewer van Apple de ship-pipeline draait. Ik ben blij dat hij op Apple's machine crashte en niet op die van een gebruiker.

De tweede afwijzing was de grappige. Apple liet me niet de zinnen "No paywall" of "No annoying IAP" gebruiken in de screenshot-tekst van de App Store-listing. Het platform dat zelf via paywalls en in-app purchases verdient, laat je op zijn store de afwezigheid daarvan niet adverteren. Ik schrijf dat als platte mededeling op omdat de ironie zelf de grap is; ik hoef hem niet aan te kleden. De metadata is zonder die tekst opnieuw ingestuurd, en de afwijzing zelf is grofweg de schoonste versie van de these die ik me had kunnen wensen, uitgespeeld als onderdeel van het lanceringsproces.

De derde was meer een verduidelijking dan een afwijzing — Apple wilde een onderbouwing voor een server entitlement waar de app om vroeg. Ik heb die opgeschreven, teruggestuurd, en die ronde was daarmee gesloten.

Het totale review-venster was ongeveer een week.

## Eerlijke caveats

De gebruikersbasis voor de lancering bestaat uit één persoon. Mijzelf. Ik heb de app gebruikt op een freelanceproject waarop ik declarabele uren bijhield — het gereedschap nodig hebben, in de Mac App Store kijken, niets gratis vinden dat het werk deed, en het ding zelf schrijven in plaats van de tol te betalen. Er is geen TestFlight-cohort, geen Hacker News-post, geen forumthread. De lancering is het begin van de feedback loop, niet het einde van een. Het plan vanaf hier is om hem naar een handvol vrienden te sturen waarvan ik weet dat ze hem een week zullen gebruiken en me echte feedback geven richting de volgende versie.

De acht jaar gat voor deze build is reëel. Het laatste Apple-platform-ding dat ik geshipped heb stond in een totaal andere context. Daar koud op terugkomen en in twee weken bij een werkende menubalk-app uitkomen is geen verhaal dat ik op een eerdere iteratie van de toolchain had kunnen vertellen. De agentic coding tools die ik tijdens de build heb gebruikt doen meer van het zware werk dan eerlijk is om weg te laten — vooral op de Apple-specifieke spreuken die je elk een dag of anderhalve dag blokkeren als je er uit oefening bent. Ik heb daar in algemenere zin over geschreven in [de adoption-gap post](/blog/the-adoption-gap); Hourly is daar het concrete voorbeeld van.

Ik ga me wat opgelaten voelen als blijkt dat Hourly een opvallende bug heeft die een echte gebruiker in de eerste week vindt. De repository heeft een test suite, de suite slaagt, maar een lancering met één gebruiker vooraf is precies het soort situatie waarin het ding waar je niet aan dacht om te testen het ding is waar de tweede gebruiker overheen struikelt. Ik hoor het liever wel dan niet.

De $99-per-jaar Apple Developer fee is de enige terugkerende kostenpost waar ik stilletjes baal van, en er is geen schone manier om die terug te verdienen terwijl de app gratis blijft. Een donatielink in de app zelf komt vermoedelijk niet langs Apple's regels. Ik laat dat waarschijnlijk verder met rust en behandel het als de kosten van het experiment.

## Waar het nu staat en wat er hierna komt

![1.00](https://media.ninokroesen.com/uploads/2026/05/d4ffd05d5e154953d7fb/_1280.jpeg)

[Hourly](/hourly) is live op [de Mac App Store](https://apps.apple.com/app/hourly-time-billing-tracker/id6762381291) en als directe download vanaf deze site. De bundle ID is `com.ninokroesen.hourly` als je wilt verifiëren dat het daadwerkelijk de app is waar ik het over heb en niet iemand anders zijn listing.

Wat ik nu ga doen is wachten en kijken. De twee aftakkingen die ik voor mezelf alvast heb getrokken:

* Als de installaties via de App Store wezenlijk bewegen — oftewel, als een gratis no-account lokale app gebruikers kan trekken in een categorie waar de gevestigde spelers geld vragen — landt de hypothese. In dat geval overweeg ik het project open-source te maken. De community zou welkom zijn om bij te dragen, de app is op dit moment oprecht kaal, en een open repo is de natuurlijke vorm voor een tool als deze. Er zit echt opschoonwerk tussen de huidige working copy en een publiceerbare repository, en dat bepaalt mede hoe snel het zou kunnen.

* Als de installaties stilvallen — oftewel, als het gemak van een betaalde app met account, sync en een gepolijste marketingsite zwaarder weegt dan het prijsvoordeel van een gratis lokale — landt de hypothese voor deze categorie niet. In dat geval zou ik de extra moeite van open-sourcen niet nemen. De app blijft gehost op deze site voor de mensen die hem vinden en draait stilletjes door op de App Store totdat Apple of ik hem afserveren. Geen actieve afschrijving; het artefact blijft gewoon staan.

Ben je een Mac-gebruiker die declarabele uren bijhoudt, dan is de installatie één klik vanaf [de projectpagina](/hourly). Vind je een bug of mis je een feature die de app niet heeft, dan is [de support-pagina](/hourly/support) de route. Vrienden waarvan ik weet dat ze hem voor mij gaan binnentrekken zijn niet de enige test set; lezers van deze post zijn nadrukkelijk onderdeel van de test set die de lancering komt verzamelen.

## Het deel dat zich generaliseert

De toolchain-bet is degene die ik meeneem naar elk toekomstig Mac-project dat ik start. Swift Package + Command Line Tools + een paar honderd regels shell — geen Xcode in de loop tenzij ik echt een SwiftUI-preview of een simulator-run wil hebben, en het grootste deel van de tijd wil ik dat niet. Het hele project is vanaf het begin tekstbestanden en versiebeheerbaar, de dev-loop zit in de editor die ik op dat moment toch al gebruik, en de build pipeline is end-to-end controleerbaar zonder de terminal te verlaten. De kost is dat je de paar dingen waar Xcode echt goed in is niet krijgt, en dat je er op de harde manier achter komt waar Apple's verstopte Xcode-veronderstelt-zichzelf-dependencies zitten. Maar zodra die zijn afgehandeld, past het resultaat in dezelfde vorm als een build voor wat dan ook.

Het andere ding dat ik meeneem is minder een toolchain en meer een discipline. Wanneer je een hypothese empirisch test, bepalen de kosten van het eerlijk uitvoeren van die test of je hem überhaupt uitvoert. Als Hourly als gepolijste SaaS had moeten shippen om de SaaS-versus-gratis-lokaal-vraag te testen, had ik mijn ogen gerold en de test niet gedraaid, en was de hypothese een mening gebleven. Twee weken bouwtijd, $99 aan kosten, geen marketing, geen groeiteam — dat is klein genoeg dat ik daadwerkelijk de knoop heb doorgehakt. De meeste van mijn meningen zijn nog steeds meningen omdat ik er geen goedkoop genoeg geworden versie van een test voor heb bedacht. De meningen die in projecten veranderen, zijn de meningen waar dat wel voor gelukt is.