Keepio

Le problème résolu

Mes tâches vivaient dans une app, mon minuteur dans une autre, et mes projets nulle part. Rien ne reliait le temps passé à ce qui avançait vraiment : je pouvais enchaîner les sessions sans savoir si un projet progressait. Keepio part du projet plutôt que de la tâche. Une liste claire, un objectif à la fois. Le Pomodoro y est intégré, donc chaque session compte pour un projet précis et laisse une trace. La progression se lit en un coup d'œil, les échéances restent dans le calendrier plutôt que dans une notification de plus. Tout se synchronise entre iPhone, iPad et Mac sans compte à créer.

Behind the scenes

Un an de développement en solo, et deux décisions structurantes que je referais à l'identique. La première : pas de modularisation SPM. Un seul target, organisé par namespaces d'enums — App.Project.Views.Editor, App.Todo.UseCases. Le conseil habituel dit de découper en modules ; sur un projet solo, le coût de la gestion des dépendances dépassait le bénéfice. Deux dépendances externes en tout, dont une que j'ai écrite moi-même. La seconde : figer les versions de schéma plutôt que de les nettoyer. Quatorze versions gelées, V1 à V14, toutes en migration légère, et aucune jamais supprimée. Quand des données synchronisées via CloudKit vivent sur les appareils de vrais utilisateurs, effacer une version passée revient à casser la mise à jour de ceux qui ont sauté deux mises à jour. Ce qui a fait mal, c'est la coupe de périmètre sur le partage de projets. La fonctionnalité était développée ; je l'ai retirée de l'interface pour sortir la version, en gardant la couche de données dormante et tout le code sur une branche. Décider d'arrêter quelque chose de fini est plus dur que de l'écrire. Le modèle économique a aussi pivoté en cours de route, de l'abonnement à l'achat unique à vie, avec les anciens abonnés conservés dans leurs droits.

Leçons apprises

• 01Un projet solo n'a pas besoin de l'architecture d'une équipe de dix personnes.
• 02Une version de schéma ne se supprime jamais : quelqu'un est resté sur l'ancienne.
• 03Retirer une fonctionnalité terminée pour sortir est une décision, pas un échec.
• 04Swift 6 en concurrence stricte coûte cher à l'adoption et se rembourse en bugs jamais écrits.
• 05Des jetons de design, aucune valeur en dur : c'est ce qui rend une refonte visuelle possible.
• 06Le modèle économique se teste comme une fonctionnalité, et se corrige de la même façon.