Créer une app de budget en solo

La plupart des applis de budget traitent l’argent comme un jeu qu’il faut gagner.

Des points pour économiser. Des séries pour tenir un journal. Des badges pour être responsable avec ton propre argent, comme si l’âge adulte avait besoin d’un nouveau classement.

Je comprends pourquoi ça existe. La gamification marche pour l’engagement. Elle pousse les gens à ouvrir l’app plus souvent. Elle crée une impression de progrès même quand les chiffres bougent lentement. Pour certains, c’est exactement ce qu’il leur faut.

Je ne fais pas partie de ces gens.

PiggyPulse n’est pas né d’une envie de créer une app de budget. Il est né d’une frustration simple : je n’en trouvais aucune qui me convenait.

Le problème : le salaire arrive le 25

Je suis payé le 25 de chaque mois. Si le 25 tombe un samedi, je suis payé le vendredi. Si c’est un dimanche, je suis payé le lundi. Ce n’est pas inhabituel pour les cycles de paie européens, mais la plupart des applis de budget supposent que ton argent arrive le 1er.

Les budgets mensuels ne fonctionnent pas quand ton mois commence le 25. Et toutes les applis que j’ai essayées voulaient soit que je m’adapte au calendrier, soit que j’accepte une période personnalisée bancale qui sentait le bricolage de dernière minute.

C’était la première lacune.

La deuxième, c’était la gamification. Je n’ai pas besoin d’un minuscule cheerleader numérique qui juge mes habitudes de dépenses. Je n’ai pas besoin d’un badge parce que je n’ai pas acheté de café. Je veux voir où va mon argent sans avoir l’impression qu’on me gronde ou qu’on me récompense pour des décisions financières normales.

J’ai cherché une app capable de gérer les périodes budgétaires personnalisées sans transformer la gestion du budget en concours de personnalité. Je n’en ai pas trouvé.

Alors j’ai décidé de la construire moi-même.

Pourquoi Rust, et pas le choix évident

Ça faisait longtemps que je voulais apprendre Rust. Pas parce que c’était tendance, mais parce que le produit que j’avais en tête devait être stable et sécurisé. Une app de budget manipule des données financières. Si j’allais demander à des gens de confier leurs relevés de comptes à quelque chose que j’avais construit, je voulais que les fondations soient solides.

Rust correspondait à ce besoin. Pas de ramasse-miettes. Pas de surprises à l’exécution. La sécurité mémoire garantie à la compilation. Pour un développeur solo qui n’a pas les moyens de chasser des segfaults à 2 heures du matin, c’est un avantage significatif.

La première version de l’API a été construite avec Rocket. Elle n’avait pas encore d’authentification — ça viendrait plus tard — mais elle pouvait traiter des requêtes et renvoyer des données. Je savais déjà que j’utiliserais Argon2 pour le hachage des mots de passe une fois l’auth ajoutée. Ce n’était pas une supposition. Mon mémoire de master portait sur les schémas de hachage de mots de passe (PHS). Certaines choses restent avec toi.

La plus moche appli web fonctionnelle du monde

Une fois l’API minimalement viable, il me fallait un frontend.

Je savais ce que je voulais que l’app fasse. Je savais comment fonctionnent les applis web. Mais je conçois les choses en ingénieur, et la première version web ressemblait exactement à ce qu’un ingénieur construit sans designer dans la pièce.

Elle fonctionnait. Elle avait les fonctionnalités dont j’avais besoin. Un app shell, des menus, un thème clair et sombre. Le tout avec les composants Mantine. Mais c’était brut. Tout était à la bonne place et rien n’avait l’air d’y être à sa place.

Ce n’était pas grave. Je construisais d’abord pour moi. Le polish viendrait plus tard.

Des agents IA qui conçoivent mon logo

À un moment donné, j’ai réalisé que ce truc commençait vraiment à prendre forme. J’avais une API qui marchait, une app web fonctionnelle, et une idée claire de ce que je voulais qu’elle fasse. C’est à ce moment-là que j’ai décidé d’arrêter de construire un outil personnel et de commencer à construire un vrai produit.

Ce changement a modifié ma façon de travailler. J’ai commencé à intégrer l’IA dans le processus — pas comme générateur de code, mais comme partenaire d’échange.

On discutait des fonctionnalités ensemble, comme deux chefs de produit dans une pièce. J’avais des opinions. L’IA avait des suggestions. Aller-retour jusqu’à ce que la liste de fonctionnalités tienne la route. Ensuite je passais en mode designer, et l’IA devenait mon critique de design. On parcourait des maquettes sur Figma, différentes versions, différentes esthétiques, jusqu’à tomber sur quelque chose qui sonnait juste.

L’app s’appelait encore « budgeting-app » et « budgeting-api » à ce stade. L’étape suivante, c’était un vrai nom et un logo.

Je voulais quelque chose de léger. Pas de graphiques, pas de cibles dans l’identité visuelle. Juste quelque chose qui apportait un peu de chaleur au monde du budget. On est tombés sur une tirelire. Simple, reconnaissable, liée à la finance sans faire corporate.

Mais l’app était construite autour des données. Tableaux de bord, tendances, suivi des dépenses. Un check du pouls de tes finances.

Une tirelire qui prend ton pouls.

PiggyPulse s’est écrit tout seul après ça.

Le nom qui a fonctionné par accident

Le nom n’est pas arrivé par une étude de marché ou des tests A/B. C’était le résultat d’une longue conversation entre moi et l’IA sur ce que l’app dégageait. La tirelire représentait la légèreté. Le pouls représentait la conscience. Mets les deux ensemble et tu obtiens une app de budget qui prend des nouvelles sans juger.

C’est toujours l’idée centrale derrière PiggyPulse. C’est une app de budget calme. Elle n’est pas là pour optimiser ta vie. Elle est là pour t’aider à remarquer ce qui se passe avec ton argent.

iOS livré, Android bloqué par un téléphone

Avec l’API et l’app web en place, j’ai mis le cap sur le mobile. Je voulais des applis natives — iOS et Android.

Je n’avais jamais construit d’app iOS ou Android avant. Je n’avais aucune idée de ce que je faisais. Alors j’ai appris les deux environnements de développement avec l’IA qui me tenait la main à chaque étape. À ce stade, j’avais aussi fait passer l’API de la v1 à la v2 pour mieux supporter plusieurs clients avec un flux cohérent.

L’app iOS a atterri sur l’App Store. C’était une étape majeure. Un développeur solo, un backend Rust, une app web Mantine, et une vraie app iOS dans le store.

L’app Android n’est pas allée plus loin. Pas parce que je ne pouvais pas la construire. J’avais besoin d’un appareil Android physique pour activer mon compte développeur Google Play, et je n’en avais tout simplement pas. C’était le blocage. Un seul morceau de matériel entre l’app et le Play Store.

Chiffrer les données, traduire l’expérience

La dernière grosse fonctionnalité que je voulais, c’était le chiffrement au repos. Si quelqu’un va stocker ses relevés financiers dans mon app, ces relevés ne devraient pas être lisibles si la base de données est compromise.

Cette migration était complexe. Tout le flux devait changer pour supporter le chiffrement côté client tout en gardant l’app fonctionnelle. Encore une fois, les agents IA ont aidé à planifier et exécuter le tout.

Ensuite sont venues les traductions. L’app était en anglais, mais je voulais qu’elle touche les gens dans leur propre langue. Je parle couramment anglais et portugais, mais les autres langues — espagnol, français, néerlandais, allemand — étaient hors de ma portée. L’IA s’est chargée des traductions. Résultat : une app multilingue construite par quelqu’un qui ne parle que deux des langues qu’elle supporte.

Plusieurs agents, un seul constructeur

Une chose à laquelle je ne m’attendais pas, c’est à quel point j’allais compter sur des agents IA pour se relire les uns les autres.

Un agent écrivait du code. Un autre le relisait. Ils faisaient des allers-retours jusqu’à ce qu’ils tombent d’accord sur une solution. Je faisais la relecture finale avant de merger, mais les premières passes étaient gérées par les agents eux-mêmes. C’était comme avoir une petite équipe sans la paie.

Autant être honnête : j’ai écrit chaque ligne de code dans les premiers stades. Chaque ligne. Mais une fois les fondations solides et le périmètre élargi, l’IA est devenue le moteur qui a rendu le développement solo viable.

Accessible à tout le monde

PiggyPulse est open source. Tout le projet — API, app web, app iOS, documentation — vit sur GitHub à github.com/leocalm/piggy-pulse.

Ce n’était pas un choix automatique. Il y a quelque chose d’inconfortable à publier son code quand on est un développeur solo. Chaque commit précipité, chaque abstraction imparfaite, chaque décision qui avait du sens à 1 heure du matin est exposée au regard de tous.

J’ai choisi l’open source pour trois raisons.

D’abord, la transparence. Si je demande aux gens de confier leurs données financières à cette app, ils doivent pouvoir voir exactement comment elle fonctionne. Le schéma de chiffrement. Les contrats de l’API. Les requêtes à la base de données. Rien de caché.

Deuxièmement, la communauté. La revue de sécurité et les idées de fonctionnalités bénéficient de perspectives variées. L’open source rend ça possible sans avoir besoin d’une équipe à plein temps.

Et troisièmement, construire au grand jour me garde honnête. Quand tu sais que d’autres personnes peuvent lire ton code, tu écris un meilleur code. Tu documentes plus. Tu réfléchis à deux fois avant de couper un coin rond.

C’est github.com/leocalm/piggy-pulse. Si tu veux voir une API Rust construite avec Rocket, le frontend React, comment le chiffrement au repos fonctionne sous le capot, ou juste lire l’historique des commits d’un projet qui a commencé comme une frustration personnelle — tout est là.

Rien de tout ça n’a été une ligne droite

En y repensant, le chemin qui a mené à un PiggyPulse livré était chaotique. Ça a commencé avec une frustration personnelle à propos des cycles de paie. C’est passé par une API Rust sans auth, une app web qui ressemblait à un dessin d’ingénieur, une phase de design guidée par l’IA, une session de nommage qui a pris plus de temps que la construction du premier prototype, un lancement iOS, un blocage Android, une migration de chiffrement, et cinq traductions.

Rien n’était planifié de bout en bout. Chaque étape a émergé de la précédente.

C’est la version honnête de la construction d’un produit en solo. Tu ne suis pas une feuille de route. Tu suis le prochain problème intéressant. Certains problèmes sont techniques. Certains sont des décisions de design. Certains sont juste le besoin d’un téléphone que tu ne possèdes pas.

Mais le résultat, c’est une app qui fait exactement ce dont j’avais besoin. Pas de gamification. Pas de jugement. Juste un endroit pour suivre ton argent à ton rythme, selon ton propre calendrier.

PiggyPulse existe parce qu’aucune des applis existantes ne convenait. Et parfois, quand rien ne convient, tu construis le tien.

Ça suffit.