Eine Budget-App als Solo-Entwickler bauen
Die meisten Budget-Apps behandeln Geld wie ein Spiel, das du gewinnen musst.
Punkte fürs Sparen. Serien fürs Erfassen. Abzeichen dafür, dass du verantwortungsvoll mit deinen eigenen Finanzen umgehst — als ob das Erwachsensein noch eine weitere Bestenliste bräuchte.
Ich verstehe, warum es das gibt. Gamification funktioniert für Engagement. Es bringt Leute dazu, die App öfter zu öffnen. Es erzeugt ein Gefühl von Fortschritt, selbst wenn sich die Zahlen nur langsam bewegen. Für manche Menschen ist genau das richtig.
Ich bin nicht einer von diesen Menschen.
PiggyPulse wurde nicht aus dem Wunsch heraus geboren, eine Budget-App zu bauen. Es entstand aus einer einfachen Frustration: Ich konnte keine finden, die zu mir passte.
Das Problem: Gehalt am 25.
Ich bekomme mein Gehalt am 25. jedes Monats. Fällt der 25. auf einen Samstag, gibt’s Geld am Freitag. Ist es ein Sonntag, am Montag. Das ist bei europäischen Gehaltszyklen nichts Ungewöhnliches, aber die meisten Budget-Apps gehen davon aus, dass dein Geld am 1. kommt.
Monatsbasierte Budgets funktionieren nicht, wenn dein Monat am 25. beginnt. Und jede App, die ich ausprobiert habe, wollte von mir, dass ich mich entweder dem Kalender anpasse oder irgendein halbgares individuelles Zeitfenster akzeptiere, das sich anfühlte wie ein nachträglicher Einfall.
Das war die erste Lücke.
Die zweite war die Gamification. Ich will keinen winzigen digitalen Cheerleader, der meine Ausgabegewohnheiten beurteilt. Ich brauche kein Abzeichen dafür, dass ich keinen Kaffee gekauft habe. Ich will sehen, wohin mein Geld fließt, ohne mich dabei gescholten oder belohnt zu fühlen für völlig normale finanzielle Entscheidungen.
Ich habe nach einer App gesucht, die individuelle Budget-Zeiträume kann, ohne Budgetieren in einen Persönlichkeitswettbewerb zu verwandeln. Ich habe keine gefunden.
Also habe ich beschlossen, sie selbst zu bauen.
Warum Rust, nicht die naheliegende Wahl
Ich wollte Rust schon lange lernen. Nicht weil es trendy war, sondern weil das Produkt, das ich im Kopf hatte, stabil und sicher sein musste. Eine Budget-App verwaltet Finanzdaten. Wenn ich Leute bitten wollte, ihre Ausgabenaufzeichnungen etwas anzuvertrauen, das ich gebaut hatte, wollte ich ein solides Fundament.
Rust hat diese Anforderung erfüllt. Kein Garbage Collector. Keine Runtime-Überraschungen. Speichersicherheit garantiert zur Compile-Zeit. Für einen Solo-Entwickler, der es sich nicht leisten kann, um 2 Uhr morgens Segfaults zu jagen, ist das ein echter Vorteil.
Die erste Version der API habe ich mit Rocket gebaut. Authentifizierung hatte sie noch nicht, das kam später. Aber sie konnte Anfragen verarbeiten und Daten zurückgeben. Ich wusste schon damals, dass ich Argon2 fürs Passwort-Hashing verwenden würde, sobald ich Auth einbaute. Das war keine Vermutung. Meine Masterarbeit handelte von Passwort-Hashing-Verfahren (PHS). Manche Dinge bleiben einfach hängen.
Die hässlichste funktionale Web-App der Welt
Als die API minimal brauchbar war, brauchte ich ein Frontend.
Ich wusste, was die App können sollte. Ich wusste, wie Web-Apps funktionieren. Aber ich entwerfe Dinge als Ingenieur, und die erste Web-Version sah genau so aus, wie das, was ein Ingenieur baut, wenn kein Designer im Raum ist.
Sie hat funktioniert. Sie hatte die Funktionalität, die ich brauchte. Sie hatte ein App-Shell, Menüs, helles und dunkles Design. Alles mit Mantine-Komponenten. Aber sie war grob. Alles war an der richtigen Stelle, und nichts sah so aus, als gehörte es dorthin.
Das war in Ordnung. Ich habe zuerst für mich selbst gebaut. Feinschliff konnte später kommen.
KI-Agenten entwerfen mein Logo
Irgendwann wurde mir klar, dass dieses Ding tatsächlich Form annahm. Ich hatte eine funktionierende API, eine funktionsfähige Web-App und eine klare Vorstellung davon, was sie tun sollte. In dem Moment habe ich beschlossen, aufzuhören, ein persönliches Werkzeug zu bauen, und stattdessen ein echtes Produkt zu entwickeln.
Dieser Wechsel hat meine Arbeitsweise verändert. Ich begann, KI in den Prozess einzubeziehen — nicht als Code-Generator, sondern als Sparringspartnerin.
Wir haben gemeinsam über Funktionen diskutiert, wie zwei Product Manager in einem Raum. Ich hatte Meinungen. Die KI hatte Vorschläge. Hin und her, bis die Feature-Liste Sinn ergab. Dann bin ich in den Design-Modus gewechselt, und die KI wurde meine Design-Kritikerin. Wir sind Mock-ups in Figma durchgegangen, verschiedene Versionen, verschiedene Ästhetiken, bis wir etwas gefunden hatten, das sich richtig anfühlte.
Die App hieß zu dem Zeitpunkt noch so etwas wie „budgeting-app” und „budgeting-api”. Der nächste Schritt war also ein richtiger Name und ein Logo.
Ich wollte etwas Leichtes. Keine Charts, keine Grafiken, keine Ziele im Branding. Einfach etwas, das ein bisschen Wärme in das Budget-Thema bringt. Wir landeten bei einem Sparschwein. Einfach, wiedererkennbar, mit Finanzen verbunden, ohne sich wie ein Konzern anzufühlen.
Aber die App war um Daten herum gebaut. Dashboards, Trends, Ausgabenkontrollen. Ein Puls-Check für deine Finanzen.
Ein Sparschwein mit Puls-Check.
PiggyPulse schrieb sich danach von selbst.
Der Name, der zufällig funktioniert hat
Der Name entstand nicht durch Marktforschung oder A/B-Tests. Er war das Ergebnis eines langen Gesprächs zwischen mir und der KI darüber, wie sich die App anfühlt. Das Sparschwein stand für Leichtigkeit. Der Puls stand für Bewusstsein. Setzt du beides zusammen, bekommst du eine Budget-App, die nachfragt, ohne zu verurteilen.
Das ist immer noch die Kernidee hinter PiggyPulse. Es ist eine ruhige Budget-App. Sie ist nicht hier, um dein Leben zu optimieren. Sie ist hier, um dir zu helfen, wahrzunehmen, was mit deinem Geld passiert.
iOS ausgeliefert, Android gescheitert an einem Telefon
Mit fertiger API und Web-App nahm ich mir das Mobile vor. Ich wollte native Apps — iOS und Android.
Ich hatte noch nie eine iOS- oder Android-App gebaut. Ich hatte keine Ahnung, was ich tat. Also habe ich beide Entwicklungsumgebungen gelernt, während mir die KI bei jedem Schritt die Hand gehalten hat. Zu diesem Zeitpunkt hatte ich die API auch von v1 auf v2 umgestellt, um mehrere Clients mit einem konsistenten Ablauf einfacher unterstützen zu können.
Die iOS-App hat es in den App Store geschafft. Das war ein großer Meilenstein. Ein Solo-Entwickler, ein Rust-Backend, eine Mantine-Web-App und eine echte iOS-App im Store.
Die Android-App kam nicht weiter. Nicht, weil ich sie nicht bauen konnte. Ich brauchte ein physisches Android-Gerät, um meinen Google-Play-Entwickleraccount zu aktivieren, und ich hatte einfach keins. Das war der Hinderungsgrund. Ein einziges Stück Hardware zwischen der App und dem Play Store.
Daten verschlüsseln, die Erfahrung übersetzen
Die letzte große Funktion, die ich haben wollte, war Verschlüsselung im Ruhezustand (Encryption-at-Rest). Wenn jemand seine Finanzdaten in meiner App speichert, sollten diese Daten nicht lesbar sein, falls die Datenbank kompromittiert wird.
Diese Migration war komplex. Der gesamte Ablauf musste geändert werden, um clientseitige Verschlüsselung zu unterstützen, während die App funktionsfähig blieb. Auch hier halfen KI-Agenten bei der Planung und Umsetzung.
Dann kamen die Übersetzungen. Die App war auf Englisch, aber ich wollte, dass sie Menschen in ihrer eigenen Sprache erreicht. Ich spreche fließend Englisch und Portugiesisch, aber die anderen Sprachen — Spanisch, Französisch, Niederländisch, Deutsch — lagen außerhalb meiner Fähigkeiten. Die KI hat die Übersetzungen übernommen. Das Ergebnis ist eine mehrsprachige App, die von jemandem gebaut wurde, der nur zwei der Sprachen spricht, die sie unterstützt.
Mehrere Agenten, ein Entwickler
Eines hatte ich nicht erwartet: wie sehr ich mich darauf verlassen würde, dass KI-Agenten die Arbeit der anderen überprüfen.
Ein Agent schrieb Code. Ein anderer reviewte ihn. Sie diskutierten hin und her, bis sie sich auf eine Lösung einigten. Ich habe die endgültige Review vor dem Mergen gemacht, aber die ersten Durchläufe übernahmen die Agenten selbst. Es fühlte sich an wie ein kleines Team — ohne die Gehaltsabrechnung.
Das sollte ich ehrlich sagen: In der Anfangsphase habe ich jede einzelne Zeile Code selbst geschrieben. Wirklich jede. Aber sobald das Fundament solide war und der Umfang wuchs, wurde die KI zum Motor, der die Solo-Entwicklung nachhaltig machte.
Für alle verfügbar
PiggyPulse ist Open Source. Das gesamte Projekt — API, Web-App, iOS-App, Dokumentation — lebt auf GitHub unter github.com/leocalm/piggy-pulse.
Das war keine automatische Entscheidung. Es ist nicht angenehm, seinen Code zu veröffentlichen, wenn man Solo-Entwickler ist. Jeder hastige Commit, jede unvollkommene Abstraktion, jede Entscheidung, die um 1 Uhr morgens sinnvoll erschien — alles liegt für jeden da draußen zur Einsicht.
Ich habe mich aus drei Gründen für Open Source entschieden.
Erstens: Transparenz. Wenn ich Leute bitte, ihre Finanzdaten dieser App anzuvertrauen, sollten sie genau sehen können, wie sie funktioniert. Das Verschlüsselungsschema. Die API-Verträge. Die Datenbankabfragen. Nichts versteckt.
Zweitens: Gemeinschaft. Sicherheitsüberprüfungen und Feature-Ideen profitieren von verschiedenen Perspektiven. Open Source macht das möglich, ohne ein Vollzeit-Team zu brauchen.
Und drittens: In der Öffentlichkeit zu bauen, hält mich ehrlich. Wenn du weißt, dass andere Leute deinen Code lesen können, schreibst du besseren Code. Du dokumentierst mehr. Du überlegst es dir zweimal, bevor du eine Abkürzung nimmst.
Es ist github.com/leocalm/piggy-pulse. Wenn du eine mit Rocket gebaute Rust-API sehen willst, das React-Frontend, wie die Verschlüsselung im Ruhezustand unter der Haube funktioniert, oder einfach die Commit-Historie eines Projekts lesen möchtest, das als persönliche Frustration begann — es ist alles da.
Nichts davon war eine gerade Linie
Rückblickend war der Weg zu einem ausgelieferten PiggyPulse chaotisch. Er begann mit einer persönlichen Frustration über Gehaltszyklen. Er führte durch eine Rust-API ohne Authentifizierung, eine Web-App, die aussah, als hätte ein Ingenieur sie gezeichnet, eine KI-gestützte Designphase, eine Namensfindung, die länger dauerte als der Bau des ersten Prototyps, einen iOS-Launch, einen Android-Hindernisgrund, eine Verschlüsselungsmigration und fünf Sprachübersetzungen.
Nichts davon war von Anfang bis Ende geplant. Jeder Schritt ergab sich aus dem vorherigen.
Das ist die ehrliche Version davon, ein Produkt allein zu bauen. Du folgst keiner Roadmap. Du folgst dem nächsten interessanten Problem. Manche Probleme sind technisch. Manche sind Design-Entscheidungen. Manche bedeuten einfach, dass dir ein Telefon fehlt, das du nicht besitzt.
Aber das Ergebnis ist eine App, die genau das tut, was ich brauchte. Keine Gamification. Keine Verurteilung. Nur ein Ort, um dein Geld in deinem eigenen Tempo und nach deinem eigenen Zeitplan zu verfolgen.
PiggyPulse existiert, weil keine der bestehenden Apps gepasst hat. Und manchmal, wenn nichts passt, baust du einfach deine eigene.
Das reicht.