Pose, 3 jours€ 4.850,00
Matériaux€ 2.310,00
TVA · 6 % rénovationauto
Total TTC€ 7.589,60
Portfolio
Disponible pour de nouveaux projets
Je construis les systèmes sur lesquels tout repose vraiment.
- Prospects
- Devis
- Chantier
- Factures
- Portail
CRM et plateformes opérationnelles sur mesure. Du premier prospect entrant à la facture soldée — chaque rôle reçoit une interface faite pour le travail qu’il effectue, plutôt qu’un seul écran où tout est caché derrière des permissions.
Stack
- TypeScript
- React
- Postgres
- Supabase
- Swift
quatre systèmes, pas une galerie
- Chantier · 14 points ouverts Project-Point Relevé de chantier et suivi de projet pour le bâtiment — « Geen enkel punt raakt kwijt ». Mon propre produit : page d’accueil, application et portail client.
Ouvert
Clôturé
Clôturé
- Dossier · 6 rôles · semaine 11 Plateforme opérationnelle Vente, planning, exécution sur chantier, logistique, comptabilité et portail client sur une seule base de données — le système dans lequel une entreprise d’installation entière passe sa journée, du premier prospect au paiement rapproché.
- Flux d’inscription · code extrait catchbox Boîtes mail jetables pour développeurs — une boîte par flux, pour que l’inscription, la facturation et les réinitialisations de mot de passe ne finissent jamais dans le même tas. Il vous donne le code à usage unique et le lien d’action, et lit les en-têtes pour expliquer pourquoi un mail est parti en spam. Node, sans dépendances.
$ catchbox code --wait
482910
copié
Lien
- macOS 27 · barre de menus Stash Un masqueur de barre de menus pour macOS 27. La réécriture dessine la barre comme une seule fenêtre et a cassé d’un coup tous les outils de cette catégorie — le dépôt documente ce qui a changé, mesuré sur une vraie machine plutôt que deviné.
Méthode
Ma façon de travailler
quatre règles, payées en incidents
-
L’exactitude avant l’astuce, partout où il y a de l’argent
Les prix par ligne, les régimes de TVA et les totaux de facture sont protégés par des contrôles d’invariants au niveau de la base, planifiés, qui n’alertent que lorsque l’état change. Une alarme qui se répète tous les quarts d’heure finit ignorée, et ne vaut plus rien à partir de là.
- En pratique
- Chaque règle monétaire est une contrainte ou un contrôle planifié, jamais un commentaire.
- Sans cette règle
- Des totaux qui divergent en silence, et un client qui le remarque avant vous.
-
Le contrôle d’accès ne se visse pas après coup
Un portail client public posé sur la même base que la comptabilité interne rend chaque policy row-level et chaque grant porteurs. Je pars du principe qu’une policy est cassée tant que je ne l’ai pas vue refuser la requête.
- En pratique
- Nouvel endpoint, nouvelle policy — et un test qui se connecte d’abord avec le mauvais compte.
- Sans cette règle
- Un seul prédicat manquant transforme un portail en export de tout.
-
Chaque incident devient une règle écrite
Tout ce qui a coûté du temps réel est documenté dans le dépôt — la règle, et l’histoire derrière. Un avertissement en prose ne fonctionne que si vous le lisez juste avant de commettre l’erreur, donc les plus importants deviennent des contrôles automatisés.
- En pratique
- La règle part avec le correctif, dans le même commit, histoire comprise.
- Sans cette règle
- La même panne deux fois, à six mois d’écart, par quelqu’un qui n’a jamais entendu parler de la première.
-
Mesuré, pas supposé
Avant d’affirmer que quelque chose fonctionne, je lance la vérification et je lis la sortie. Cette habitude fait toute la différence entre un système auquel on se fie et un système sur lequel on espère.
- En pratique
- Pas de « ça devrait marcher ». Lancer, lire, et citer la ligne qui le prouve.
- Sans cette règle
- Un déploiement vert dans votre tête et rouge en production.
Lancer la vérification, lire la sortie, ensuite dire que ça marche.