Een budgetapp bouwen als solo-ontwikkelaar

De meeste budgetapps doen alsof geld een spel is dat je moet winnen.

Punten voor sparen. Streaks voor bijhouden. Badges voor verantwoordelijk omgaan met je eigen financiën — alsof volwassenheid nog een klassement nodig had.

Ik snap waarom het bestaat. Gamificatie werkt voor betrokkenheid. Het zorgt dat mensen de app vaker openen. Het geeft een gevoel van vooruitgang, zelfs als de cijfers maar langzaam bewegen. Voor sommige mensen is dat precies wat ze nodig hebben.

Ik ben niet een van die mensen.

PiggyPulse is niet ontstaan uit de wens om een budgetapp te bouwen. Het ontstond uit een simpele frustratie: ik kon er geen vinden die bij me paste.

Het probleem: salaris op de 25e

Ik krijg mijn salaris op de 25e van elke maand. Als de 25e op een zaterdag valt, krijg ik het op vrijdag. Als het een zondag is, krijg ik het op maandag. Dit is niet vreemd voor Europese salariscycli, maar de meeste budgetapps gaan ervan uit dat je geld op de 1e binnenkomt.

Maandelijkse budgetten werken niet als jouw maand op de 25e begint. En elke app die ik probeerde, wilde dat ik me aanpaste aan de kalender of genoegen nam met een of ander halfbakken aangepast tijdvak dat aanvoelde als een bijzaak.

Dat was de eerste kloof.

De tweede was de gamificatie. Ik wil geen piepkleine digitale aanmoediger die mijn uitgavenpatroon beoordeelt. Ik heb geen badge nodig omdat ik geen koffie heb gekocht. Ik wil gewoon zien waar mijn geld naartoe gaat zonder het gevoel te hebben dat ik op mijn kop krijg of een beloning krijg voor normale financiële beslissingen.

Ik zocht naar een app die met aangepaste budgetperiodes kon omgaan zonder van budgetteren een persoonlijkheidswedstrijd te maken. Ik vond er geen.

Dus besloot ik er zelf een te bouwen.

Waarom Rust — niet de voor de hand liggende keuze

Ik wilde al een tijdje Rust leren. Niet omdat het trendy was, maar omdat het product dat ik in gedachten had stabiel en veilig moest zijn. Een budgetapp verwerkt financiële gegevens. Als ik mensen zou vragen om hun uitgaven aan iets toe te vertrouwen wat ik had gebouwd, wilde ik dat de basis solide was.

Rust voldeed aan die eis. Geen garbage collector. Geen runtime-verrassingen. Geheugenveiligheid gegarandeerd tijdens het compileren. Voor een solo-ontwikkelaar die niet om 2 uur ‘s nachts achter segfaults aan kan zitten, is dat een serieus voordeel.

De eerste versie van de API was gebouwd met Rocket. Er zat nog geen authenticatie in — dat kwam later — maar het kon verzoeken afhandelen en data teruggeven. Ik wist al dat ik Argon2 zou gebruiken voor het hashen van wachtwoorden zodra ik auth zou toevoegen. Dat was geen gok. Mijn masterscriptie ging over wachtwoordhashschema’s (PHS). Sommige dingen blijven je bij.

’s Werelds lelijkste functionele webapp

Zodra de API minimaal bruikbaar was, had ik een frontend nodig.

Ik wist wat ik wilde dat de app deed. Ik wist hoe webapps werken. Maar ik ontwerp dingen als ingenieur, en de eerste webversie zag er precies zo uit als wat een ingenieur bouwt zonder een ontwerper in de ruimte.

Het werkte. Het had de functionaliteit die ik nodig had. Het had een app-shell, menu’s, een lichte en donkere modus. Allemaal met Mantine-componenten. Maar het was grof. Alles stond op de juiste plek, maar niets zag eruit alsof het er thuishoorde.

Dat was oké. Ik bouwde het in de eerste plaats voor mezelf. Verfijning kon later komen.

AI-agents die mijn logo ontwierpen

Op een gegeven moment besefte ik dat dit ding echt bij elkaar kwam. Ik had een werkende API, een functionele webapp en een helder idee van wat ik ermee wilde doen. Dat was het moment waarop ik besloot te stoppen met het bouwen van een persoonlijk hulpmiddel en te beginnen met het bouwen van een echt product.

Die verschuiving veranderde hoe ik werkte. Ik begon AI in het proces te betrekken — niet als codegenerator, maar als sparringpartner.

We bespraken samen functies, als twee productmanagers in een kamer. Ik had meningen. AI had suggesties. Heen en weer totdat de functielijst logisch was. Daarna schakelde ik over naar ontwerper-modus, en AI werd mijn ontwerpcriticus. We gingen door mock-ups in Figma, verschillende versies, verschillende esthetieken, totdat we iets vonden dat goed voelde.

De app heette op dat punt nog steeds zoiets als “budgeting-app” en “budgeting-api”. Dus de volgende stap was een echte naam en logo.

Ik wilde iets lichts. Geen grafieken, geen diagrammen, geen doelen in de huisstijl. Gewoon iets dat een beetje warmte bracht in het budgetteren-scenario. We kwamen uit op een spaarvarken. Eenvoudig, herkenbaar, verbonden met financiën zonder zakelijk aan te voelen.

Maar de app was gebouwd rond data. Dashboards, trends, uitgavencontroles. Een polscontrole van je financiën.

Een spaarvarken met een polscontrole.

PiggyPulse schreef zichzelf daarna vanzelf.

De naam die per ongeluk werkte

De naam was niet het resultaat van marktonderzoek of A/B-testen. Het was het resultaat van een lang gesprek tussen mij en AI over hoe de app aanvoelde. Het spaarvarken stond voor lichtheid. De pols stond voor bewustzijn. Zet ze bij elkaar en je krijgt een budgetapp die checkt-in zonder te oordelen.

Dat is nog steeds het kernidee achter PiggyPulse. Het is een rustige budgetapp. Het is er niet om je leven te optimaliseren. Het is er om je te helpen opmerken wat er met je geld gebeurt.

iOS gelanceerd, Android geblokkeerd door een telefoon

Met de API en webapp op orde richtte ik mijn zinnen op mobiel. Ik wilde native apps — iOS en Android.

Ik had nog nooit een iOS- of Android-app gebouwd. Ik had geen idee waar ik mee bezig was. Dus leerde ik beide ontwikkelstromen met AI die me bij elke stap bij de hand nam. Tegen die tijd had ik de API ook van v1 naar v2 verplaatst om meerdere clients makkelijker te kunnen ondersteunen met een consistente flow.

De iOS-app haalde de App Store. Dat was een grote mijlpaal. Een solo-ontwikkelaar, een Rust-backend, een Mantine-webapp en een echte iOS-app in de store.

De Android-app kwam niet verder. Niet omdat ik hem niet kon bouwen. Ik had een fysiek Android-apparaat nodig om mijn Google Play-ontwikkelaarsaccount te activeren, en ik had er simpelweg geen. Dat was de blokkade. Eén stuk hardware tussen de app en de Play Store.

Data versleutelen, de ervaring vertalen

De laatste grote functie die ik wilde, was encryptie-at-rest. Als iemand zijn financiële gegevens in mijn app opslaat, mogen die gegevens niet leesbaar zijn als de database wordt gecompromitteerd.

Die migratie was complex. De hele flow moest veranderen om client-side encryptie te ondersteunen terwijl de app functioneel bleef. Opnieuw hielpen AI-agents met het plannen en uitvoeren.

Toen kwamen de vertalingen. De app was in het Engels, maar ik wilde dat het mensen in hun eigen taal zou bereiken. Ik spreek vloeiend Engels en Portugees, maar de andere talen — Spaans, Frans, Nederlands, Duits — vielen buiten mijn bereik. AI verzorgde de vertalingen. Het resultaat was een meertalige app, gebouwd door iemand die maar twee van de ondersteunde talen spreekt.

Meerdere agents, één bouwer

Iets wat ik niet had verwacht, was hoeveel ik zou vertrouwen op AI-agents die elkaars werk beoordelen.

De ene agent schreef code. Een andere bekeek het. Ze gingen heen en weer tot ze het eens waren over een oplossing. Ik deed de eindcontrole voor ik iets merge, maar de eerste rondes werden door de agents zelf afgehandeld. Het voelde alsof ik een klein team had, zonder de loonkosten.

Het is eerlijk om hier open over te zijn: in de beginfase schreef ik elke regel code. Echt elke regel. Maar toen de basis eenmaal solide was en de reikwijdte groeide, werd AI de motor die solo-ontwikkeling haalbaar maakte.

Voor iedereen beschikbaar

PiggyPulse is open source. Het hele project — API, webapp, iOS-app, docs — staat op GitHub op github.com/leocalm/piggy-pulse.

Dit was geen automatische keuze. Er is iets ongemakkelijks aan het publiceren van je code als je een solo-ontwikkelaar bent. Elke gehaaste commit, elke imperfecte abstractie, elke beslissing die om 1 uur ‘s nachts logisch leek, ligt voor iedereen klaar om te bekijken.

Ik heb gekozen voor open source om drie redenen.

Ten eerste, transparantie. Als ik mensen vraag hun financiële gegevens aan deze app toe te vertrouwen, moeten ze precies kunnen zien hoe het werkt. Het encryptieschema. De API-contracten. De database-queries. Niets verborgen.

Ten tweede, gemeenschap. Beveiligingscontroles en functie-ideeën profiteren van diverse perspectieven. Open source maakt dat mogelijk zonder een fulltime team.

En ten derde, in de openheid bouwen houdt me eerlijk. Als je weet dat anderen je code kunnen lezen, schrijf je betere code. Je documenteert meer. Je denkt twee keer na voordat je een hoek afsnijdt.

Het is github.com/leocalm/piggy-pulse. Als je een Rust-API gebouwd met Rocket wilt zien, de React-frontend, hoe de encryptie-at-rest onder de motorkap werkt, of gewoon de commit-geschiedenis van een project dat begon als een persoonlijke frustratie wilt lezen — het ligt er allemaal.

Geen van dit was een rechte lijn

Als ik terugkijk, was het pad naar een gelanceerde PiggyPulse rommelig. Het begon met een persoonlijke frustratie over salariscycli. Het ging door een Rust-API zonder auth, een webapp die eruitzag alsof hij door een ingenieur was getekend, een AI-gestuurde ontwerpfase, een naamgevingssessie die langer duurde dan het bouwen van het eerste prototype, een iOS-lancering, een Android-blokkade, een encryptie-migratie en vijf taalvertalingen.

Geen ervan was van begin tot eind gepland. Elke stap ontstond uit de vorige.

Dat is de eerlijke versie van alleen een product bouwen. Je volgt geen routekaart. Je volgt het volgende interessante probleem. Sommige problemen zijn technisch. Sommige zijn ontwerpbeslissingen. Sommige zijn gewoon het nodig hebben van een telefoon die je niet hebt.

Maar het resultaat is een app die precies doet wat ik nodig had. Geen gamificatie. Geen oordeel. Gewoon een plek om je geld bij te houden op je eigen tempo, op je eigen schema.

PiggyPulse bestaat omdat geen van de bestaande apps paste. En soms, als niets past, bouw je je eigen.

Dat is genoeg.