Build vs Buy : Le guide pratique pour les indie hackers

Vous êtes seul. Peut-être deux. Vous avez un produit à livrer, des clients à supporter, et une page marketing qui dit encore « Coming Soon » à trois endroits. Et maintenant vous devez décider : développer cette fonctionnalité vous-même ou payer quelqu'un d'autre ?

Cette décision est la plus grosse erreur d'allocation de temps des indie hackers. Développez la mauvaise chose et vous perdez des semaines. Achetez la mauvaise chose et vous gaspillez de l'argent tout en ajoutant une dépendance que vous ne contrôlez pas.

Voici un framework qui fonctionne vraiment quand on est une équipe d'un seul.

La réponse par défaut devrait être « Acheter »

C'est contre-intuitif pour la plupart des développeurs. On est devenus indie hackers parce qu'on aime construire. Mais construire est la chose la plus coûteuse qu'on puisse faire. Votre temps est votre seule ressource, et chaque heure passée à construire de l'infrastructure est une heure de moins sur votre produit principal.

Le calcul est simple. Si un outil coûte 20 $/mois et vous fait économiser 40 heures de développement plus 2 heures/mois de maintenance, il faudrait valoriser votre temps à moins de 0,50 $/h pour justifier de le faire vous-même.

Donc la réponse par défaut est : acheter. Puis demandez-vous s'il y a une raison valable de passer outre.

Quand développer soi-même

Il y a exactement quatre situations où construire a plus de sens :

1. C'est votre avantage concurrentiel

Si la fonctionnalité est la raison pour laquelle les clients vous choisissent, vous devez en être propriétaire. Stripe a construit son propre traitement de paiement parce que le paiement EST leur produit. Vous ne devriez pas construire votre propre système de paiement.

Le test : Un client quitterait-il un concurrent pour vous à cause de votre implémentation de cette fonctionnalité spécifique ? Si oui, construisez. Si non, achetez.

2. Aucun bon outil n'existe

Parfois le marché n'a pas rattrapé. Peut-être que vous avez besoin d'une intégration très spécifique. Dans ce cas, construire est ok — mais fixez une limite de temps. Si vous ne pouvez pas construire une version fonctionnelle en une semaine, le périmètre est mauvais.

3. L'outil crée un verrouillage inacceptable

Si quitter un outil nécessiterait de réécrire une partie centrale de votre app, réfléchissez. L'hébergement de base de données ? Ok — vos données sont portables. Un moteur de workflow propriétaire qui stocke toute votre logique métier ? Dangereux.

4. Le coût évolue mal

Certains outils facturent par utilisateur, par événement ou par appel API. Si vous pouvez prévoir un futur où l'outil coûte plus que vos revenus, c'est un vrai problème. Cherchez d'abord des alternatives à tarif fixe.

Un exemple concret : la collecte de feedback

Disons que vous voulez ajouter un widget de feedback à votre SaaS. Trois options :

Option A : Le développer. Formulaire, endpoint API, table en base, dashboard. Puis notifications. Puis les utilisateurs veulent du suivi de sentiment. Puis une roadmap publique. Minimum 3-4 semaines, plus la maintenance éternelle.

Option B : Un outil enterprise complexe. 79 $/mois pour une plateforme avec 200 fonctionnalités inutiles. Une semaine de configuration. 948 $/an pour un outil surdimensionné.

Option C : Un outil ciblé. Deux lignes de code, le feedback arrive. L'outil coûte 0-20 $/mois et gère le widget, le dashboard, le sentiment, la roadmap et le changelog. 5 minutes au lieu de 4 semaines.

L'option C est presque toujours la bonne réponse. Des outils comme Palmframe existent précisément pour ça — installation en deux lignes, plan gratuit pour démarrer, et un ensemble de fonctionnalités ciblé.

Le coût caché de construire

Quand vous construisez, vous ne payez pas que le coût initial. Vous signez pour :

• Corrections de bugs — les utilisateurs trouveront des cas limites
• Correctifs de sécurité — surtout pour tout ce qui est exposé aux utilisateurs
• Demandes de fonctionnalités — « est-ce que le formulaire peut aussi faire X ? »
• Coûts d'infrastructure — hébergement, monitoring, sauvegardes
• Coût d'opportunité — chaque heure de maintenance est une heure non investie dans la croissance

Multipliez tout ça par « pour toujours ». C'est le vrai coût.

Le stack indie hacker

Voici une liste pratique de ce qu'il faut acheter vs construire pour un SaaS typique :

Acheter (presque toujours) :

• Authentification (Clerk, Auth0, ou natif au framework)
• Paiements (Stripe, Lemon Squeezy)
• Email (Resend, Postmark)
• Collecte de feedback (Palmframe)
• Monitoring d'erreurs (Sentry)
• Analytics (Plausible, PostHog)

Construire (c'est votre produit) :

• Votre fonctionnalité principale — ce pour quoi les utilisateurs paient
• Workflows personnalisés spécifiques à votre domaine

La règle unique

En cas de doute, demandez-vous : « Si je passe cette semaine à construire ça, mes clients le remarqueront-ils ? »

Si la réponse est non — si vous construisez de l'infrastructure, des outils internes ou des fonctionnalités qui existent déjà ailleurs — achetez et passez cette semaine sur quelque chose pour lequel les clients paieront.

Votre avantage concurrentiel n'est pas votre widget de feedback, votre système d'auth ou votre pipeline d'emails. C'est le truc que vous seul pouvez construire. Investissez votre temps là-dessus.