·6 min read

Build vs buy : quand construire sur mesure vaut le coup

Auth custom ou Auth0 ? Email maison ou Resend ? Mes critères pour trancher entre SaaS et développement sur mesure, avec des exemples concrets.

TL;DR

Inner Gallery : chiffrement custom (avantage compétitif). Coachy : auth et email via des SaaS (aucun avantage à les reconstruire). La règle : build ce qui te différencie, buy le reste.

Auth0 ou auth maison ? Resend ou serveur SMTP ? Mixpanel ou analytics custom ? Ces décisions façonnent ton architecture pour les 5 prochaines années.

Les 4 critères qui décident tout

1. Le coût à long terme

Le SaaS semble moins cher au début. 29$/mois pour Resend, c'est peanuts comparé à 2 semaines de développement email. Mais multiplie par 5 ans.

Pour Inner Gallery (app locale), l'email n'était même pas nécessaire. Économie : 1 740$/an. Pour Coachy (qui aura des comptes utilisateurs), j'ai construit un système d'email simple avec Nodemailer. Coût : 0$ après développement.

Ma règle : si le coût SaaS dépasse 2 000$/an, je considère sérieusement le custom.

Les SaaS coûtent souvent moins cher la première année, mais plus cher sur 5 ans. Pense total cost of ownership.

2. Le niveau de contrôle nécessaire

Avec un SaaS, tu dépends de leurs décisions. Changement de pricing, deprecated features, acquisition par un concurrent...

Pour l'auth de Coachy, j'ai choisi custom. Pourquoi ? Je voulais une intégration parfaite avec mon système d'Event Sourcing. Les solutions SaaS m'imposaient leurs modèles de données.

Résultat : auth JWT + refresh tokens + EventStore custom. Plus de travail initial, mais contrôle total sur l'UX et les performances.

3. La différenciation compétitive

Si tu peux copier-coller du code d'auth classique, autant prendre Auth0. Mais si ton auth devient un avantage concurrentiel, investis dedans.

Inner Gallery : l'auth par PIN + biométrie locale était cruciale pour l'UX. Aucun SaaS ne proposait cette combinaison spécifique. Custom obligé.

4. La scalabilité future

Les SaaS scaling sont chers. Stripe prend 2,9% + 0,30€. Acceptable au début, problématique à 100k€/mois de CA.

Mais construire un système de paiement from scratch ? Suicide. La réglementation, la sécurité, les intégrations bancaires... Stripe vaut son prix.

Ma règle : si la feature est dans le core business (paiement pour une app financière), je considère le custom. Sinon, SaaS.

Authentication : Custom (PIN + biométrie)

Pourquoi custom :

  • UX spécifique (déverrouillage par PIN/Face ID)
  • App entièrement locale, pas besoin de serveur auth
  • Sécurité critique (photos privées)

Temps investi : 3 jours

Coût évité : N/A (aucun SaaS équivalent)

Analytics : Aucun

Pourquoi ni SaaS ni custom :

  • Promise de confidentialité (zéro tracking)
  • App Store Analytics suffisent pour les métriques business
  • Chaque analytics SaaS viole ma promesse de privacy

Temps économisé : 5 jours

Coût évité : 300$/mois (Mixpanel)

Crash reporting : Custom basique

Pourquoi custom :

  • Privacy-first approach
  • Logs simples stockés localement
  • Remontée manuelle par utilisateur

Alternative évaluée : Crashlytics (gratuit mais Google)

Mes choix pour Coachy

Authentication : Custom (JWT + EventStore)

Pourquoi custom :

  • Intégration native avec l'Event Sourcing
  • Modèle de données spécifique (coach/client)
  • Coût Auth0 prohibitif à terme (5$/utilisateur/mois)

Temps investi : 1 semaine

Coût évité : 500$/mois projeté

Email : Custom (Nodemailer + SMTP)

Pourquoi custom :

  • Templates personnalisés pour coaching
  • Intégration avec EventStore (historique complet)
  • Volume prévisible (<10k emails/mois)

Alternative évaluée : Resend (29$/mois) → économie 348$/an

Push notifications : SaaS (Firebase)

Pourquoi SaaS :

  • Complexité technique énorme (iOS + Android)
  • Pas de différenciation compétitive
  • Fiabilité critique, déléguer aux experts

Coût : Gratuit jusqu'à 10M messages/mois

Build quand c'est ton avantage concurrentiel. Buy quand c'est de la plomberie standard. Simple mais efficace.

Les erreurs classiques

Over-engineering par ego

J'ai passé 2 semaines à construire un système de cache Redis custom pour Coachy. Résultat : 0,01% d'amélioration de performance pour un coût de maintenance énorme.

Leçon : n'optimise que ce qui compte. Premature optimization is the root of all evil.

Sous-estimer la maintenance

Ton code custom, c'est toi qui le maintiens à vie. Bugs, mises à jour, évolutions... Un SaaS, c'est délégué.

Pour chaque décision "build", je multipie le temps de développement initial par 3. Ça couvre la maintenance sur 3 ans. Si ça reste rentable vs SaaS, j'y vais.

Ignorer les coûts cachés

SaaS = coût visible mensuel. Custom = coût caché de ton temps. Estime ton taux journalier, multiplie par les jours de dev, et compare avec le coût SaaS sur 2-3 ans.

Framework de décision

Pour chaque feature, je me pose 4 questions :

  1. Différenciation : Cette feature me distingue-t-elle de la concurrence ?
  2. Contrôle : Ai-je besoin de personnalisation poussée ?
  3. Coût 5 ans : Custom vs SaaS, qui gagne sur la durée ?
  4. Maintenance : Ai-je le temps/envie de maintenir ça ?

Si 3 réponses sur 4 penchent "custom", je développe. Sinon, SaaS.

Les cas où SaaS gagne toujours

Compliance et réglementation

Paiement (PCI DSS), email marketing (RGPD), stockage de données santé... La réglementation change constamment. Les SaaS spécialisés suivent ces évolutions.

Construire une solution paiement RGPD-compliant from scratch ? Good luck.

Intégrations tierces

Zapier connecte 5 000+ services. Reconstruire ces intégrations prendrait des années. Même logique pour les CRM, outils de support, etc.

Expertise métier complexe

ML, computer vision, NLP... Sauf si c'est ton core business, délègue aux experts. OpenAI pour le text, Algolia pour la search.

Construire des produits à côté

Quand tu développes des produits en parallèle de ton activité principale, le temps devient ta ressource la plus précieuse.

Ma règle stricte : maximum 20% de custom par projet. Le reste en SaaS ou solutions existantes. Sinon, tu ne sortiras jamais ton produit.

Inner Gallery : 80% Swift standard + 20% sécurité custom (CryptoKit d'Apple)

Coachy : 70% Flutter/NestJS classique + 30% Event Sourcing custom

Build vs Buy est une question de business. Construis ce qui te différencie, achète le reste. Ton temps est limité, utilise-le à bon escient.

À lire aussi

build-vs-buysaasdéveloppementstartuparchitecture