Un client m'a appelé en 2021 — la vraie panique dans la voix. Il avait dépensé 140 000 £ en quatorze mois pour construire une plateforme de facturation personnalisée. Son équipe de dev en avait livré environ 60 %. Et vers le onzième mois, il avait découvert qu'Invoice Ninja existait, qu'il était open-source, et qu'il faisait 90 % de ce dont il avait besoin directement. Gratuitement.Invoice Ninja existed, was open-source, and did 90% of what he needed out of the box. For free.
Enseignement principal : Achetez du SaaS jusqu'au moment où la taxe d'abonnement, la propriété des données ou l'incompatibilité du flux de travail devient réellement problématique ; développez du sur mesure quand l'outil est au cœur de la façon dont l'entreprise gagne.Buy SaaS until the subscription tax, data ownership, or workflow mismatch genuinely bites; build custom when the tool is core to how the business wins.
Cet appel me hante un peu. Parce que la réponse honnête, c'est que j'ai aussi commis l'erreur inverse. Seahawk a eu un projet en 2019 où nous avons passé huit mois à assembler cinq outils SaaS différents — Airtable, Zapier, Typeform, HubSpot, et un CMS Webflow personnalisé — pour gérer un flux de travail client qui, rétrospectivement, aurait pu être résolu proprement et définitivement par une construction personnalisée de 15 000 £. On payait environ 900 £/mois en souscriptions combinées à la fin. Fais les calculs sur trois ans.
Aucun extrême n'est automatiquement correct. Et quiconque te vend une règle nette — « toujours construire », « ne jamais construire » — vend quelque chose. Alors voici le cadre réel que j'utilise quand un fondateur s'assoit avec moi et pose la question.
---
Premièrement, admettre ce que vous décidez réellement
Ce n'est pas une décision technique. Pas vraiment. C'est une décision commerciale déguisée en termes techniques.
Quand tu dis « devrais-je construire ou acheter ? », ce que tu demandes vraiment, c'est : où vit la différenciation dans mon produit ? Si ce que tu envisages de construire est au cœur de ton avantage concurrentiel — la raison pour laquelle les clients te choisiront plutôt que l'onglet suivant dans leur navigateur — alors la construction a probablement du sens. Si c'est de l'infrastructure, de l'administration, ou une fonctionnalité de base, l'achat est presque certainement moins cher en réalité.reason customers will choose you over the next tab in their browser -- then building probably makes sense. If it's infrastructure, admin, or commodity functionality, buying is almost certainly cheaper in real terms.
Je pose d'abord une question aux fondateurs : Vos utilisateurs verront-ils jamais cette chose ? Si la réponse est oui et que cela façonne leur expérience de façon significative, cela pourrait valoir la peine de construire. Si c'est du back-office, opérationnel, ou interne, le seuil pour construire devrait être très élevé.Will your users ever see this thing?If the answer is yes and it shapes their experience in a meaningful way, it might be worth building. If it's back-office, operational, or internal, the bar for building should be very high.
---
Le Vrai Coût de la Construction (Les Gens le Sous-estiment Gravement)
Soyons direct. Le développement sur mesure coûte plus cher que tu le penses, prend plus longtemps qu'on te le dit, et demande une maintenance permanente que personne ne budgétise.
Ce que les fondateurs oublient réellement de compter
- Maintenance et hébergement. Pas un travail ponctuel. Vous en êtes responsable indéfiniment, sauf si vous abandonnez la chose.Not a one-off. You're on the hook forever unless you sunset the thing.
- Correctifs de sécurité. Un fournisseur SaaS s'en charge pour vous. Vous la construisez, vous en êtes propriétaire, y compris les alertes à 2 h du matin.A SaaS vendor handles this for you. You build it, you own it, including the 2am alerts.
- Intégration de nouveaux développeurs. Si votre ingénieur principal part, la personne suivante doit apprendre votre codebase. C'est des semaines de travail facturable.If your lead engineer leaves, the next person needs to learn your codebase. That's weeks of billable time.
- Expansion du périmètre. Les parties prenantes voient un outil personnalisé et supposent qu'il peut faire tout. Le périmètre s'élargit. Les coûts suivent.Stakeholders see a custom tool and assume it can do everything. Scope expands. Costs follow.
Une règle approximative que j'utilise : prenez votre estimation initiale de développement, multipliez par 1,6 pour une livraison réaliste, puis ajoutez 20% de ce chiffre annuellement pour la maintenance. Si ces chiffres justifient toujours le modèle économique, parfait. Si ce n'est pas le cas, vous avez votre réponse.
Honnêtement, le CHAOS Report du Standish Group montre depuis des décennies que les projets logiciels dépassent leurs budgets à un taux alarmant. Le chiffre tourne autour de 45-50 % des projets étant « en difficulté » ou carrément échoués. Ce n'est pas une raison de ne jamais construire — c'est une raison d'y aller les yeux ouverts.Standish Group's CHAOS Report has been showing for decades that software projects overrun their budgets at an alarming rate. The number sits around 45-50% of projects being "challenged" or outright failing. That's not a reason to never build -- it's a reason to go in clear-eyed.
---
Le vrai coût du SaaS (aussi sous-estimé, simplement différemment)
Le SaaS semble bon marché jusqu'à ce qu'il ne le soit plus.
Le plan à 49 £/mois qui semblait raisonnable au début de l'année a le curieux travers de devenir 490 £/mois à la fin de l'année trois — une fois que tu es passé à un forfait supérieur, tu as ajouté des sièges, et le vendeur a fait une « restructuration tarifaire » (lisez : augmentation). J'ai vu ça arriver à des clients sur Salesforce, Intercom, et Mixpanel. Ce n'est pas malveillant. C'est juste comme fonctionnent les économies du SaaS.
Les trois pièges du SaaS dans lesquels les fondateurs tombent
- L'enfermement propriétaire. Vos données sont dans leur format, leur schéma, leur flux d'export. Partir est douloureux et parfois effectivement impossible sans travail d'ingénierie de données considérable.Your data is in their format, their schema, their export flow. Leaving is painful and sometimes effectively impossible without significant data engineering work.
- La complexité de la Frankenstein-stack. Cinq outils qui s'intègrent vaguement via Zapier, ce n'est pas un système. C'est un passif. Une dépréciations d'API et tout commence à s'effondrer.Five tools that sort-of integrate via Zapier is not a system. It's a liability. One API deprecation and things start falling apart.
- Le dérapage des abonnements. Personne n'audite sa stack d'outils annuellement. Ils devraient. J'ai réalisé un audit pour une agence de 12 personnes l'année dernière et j'ai trouvé £3 200/mois en SaaS qu'ils avaient soit arrêté d'utiliser, soit utilisaient pour une seule fonctionnalité chacun.Nobody audits their tool stack annually. They should. I ran an audit for a 12-person agency last year and found £3,200/month in SaaS they'd either stopped using or were using for one feature each.
Cela dit — pour les fonctions de base, le SaaS est presque toujours le bon choix. Livraison d'e-mails ? Postmark ou SendGrid. Paiements ? Stripe, évidemment. Auth ? Auth0 ou Clerk. Personne ne devrait construire son propre processeur de paiement en 2024.Postmark or SendGrid. Payments? Stripe, obviously. Auth? Auth0 or Clerk. Nobody should be building their own payment processor in 2024.
---
Un Framework Qui Fonctionne Réellement
D'accord. Voici comment je réfléchis à la question. Quatre questions, dans l'ordre.
Question 1 : Est-ce un différenciateur concurrentiel ?
Si oui — si c'est ce qui rend ton produit véritablement différent — la construction vaut vraiment la peine d'être considérée. Si non, arrête ici. Achète.
Question 2 : Existe-t-il une bonne alternative SaaS ?
Une bonne alternative, pas parfaite. Les fondateurs construisent régulièrement parce que « rien sur le marché ne fait exactement ce dont nous avons besoin ». Parfois c'est vrai. Souvent cela signifie qu'ils n'ont pas cherché assez dur, ou ils confondent « nous devons bien configurer ceci » avec « nous devons construire quelque chose de nouveau ».
Je passe au moins deux heures à rechercher le marché du SaaS avant de jamais recommander une construction personnalisée. Product Hunt et G2 sont véritablement utiles ici — pas comme parole d'évangile, mais comme un inventaire de départ.Product Hunt and G2 are genuinely useful here -- not as gospel but as a starting inventory.
Question 3 : Quel est votre délai réaliste avant de générer de la valeur ?
Un outil SaaS peut être en ligne aujourd'hui. Une construction personnalisée demande des semaines minimum, généralement des mois. Si la rapidité compte -- et dans les jeunes entreprises c'est presque toujours le cas -- acheter vous achète du temps pour apprendre ce dont vous avez réellement besoin avant de vous engager à le construire.
En 2022, Seahawk a travaillé avec une startup logistique qui voulait un tableau de bord personnalisé d'optimisation des trajets. Nous les avons convaincus d'utiliser d'abord une couche API en marque blanche (ils ont utilisé Route4Me comme point de départ). Six mois plus tard, ils savaient exactement quelles trois fonctionnalités leurs clients recherchaient réellement. La construction personnalisée qu'ils ont finalement commandée avait la moitié de l'envergure -- et était deux fois meilleure -- parce qu'ils avaient appris en production plutôt que dans un document de spécifications.Route4Me as a starting point). Six months later, they knew exactly which three features their customers actually cared about. The custom build they eventually commissioned was half the scope -- and twice as good -- because they'd learned in production rather than in a spec document.
Question 4 : Que se passe-t-il quand ça tombe en panne ?
Parce que ça va casser. La question est qui le répare et à quelle vitesse. Avec SaaS, vous déposez un ticket d'assistance et vous vous plaignez sur Twitter. Avec un logiciel personnalisé, vous appelez votre équipe de développement. Si vous n'avez pas d'équipe de développement retenue, vous êtes en difficulté. Ce n'est pas hypothétique -- j'ai vu des fondateurs bloqués avec un logiciel personnalisé cassé pendant des semaines parce que leur développeur freelance était en vacances.
---
Quand la Construction Est Clairement le Bon Choix
Il y a des situations où le sur mesure est clairement correct. Laissez-moi les nommer sans détour.
- Votre propriété intellectuelle fondamentale est le logiciel lui-même. Si vous vendez un produit SaaS, vous ne pouvez pas externaliser la chose que vous vendez.If you're selling a SaaS product, you can't outsource the thing you're selling.
- Les exigences réglementaires signifient que prêt-à-l'emploi ne suffira pas. Certaines applications fintech, santé et légales ont des contraintes de conformité que la plupart des outils SaaS ne sont pas construits pour satisfaire.Certain fintech, healthcare, and legal applications have compliance constraints that most SaaS tools aren't built to satisfy.
- Vous avez déjà validé avec un outil SaaS et vous savez exactement ce dont vous avez besoin. C'est la meilleure position possible avant de commander une construction personnalisée.This is the best possible position to be in before commissioning a custom build.
- Le prix SaaS à grande échelle est véritablement plus cher que la propriété. Faites les calculs à votre utilisation projetée de l'année 3. Parfois, la construction personnalisée gagne sur la pure économie.Do the maths at your projected Year 3 usage. Sometimes custom wins on pure economics.
---
Quand acheter est clairement le bon choix
De même, certaines situations rendent l'achat évident :
- Vous êtes pre-revenue ou pre-product-market fit. C'est tout.
- La fonction est une infrastructure de commodité -- email, paiements, authentification, stockage, analytique.
- Vous en avez besoin qui fonctionne ce trimestre, pas cette année.
- Votre équipe n'a pas de capacité engineering en interne et vous ne pouvez pas vous permettre d'embaucher correctement.
J'ajouterais aussi : si tu construis en tant que fondateur pour éviter de prendre une décision commerciale plus difficile, ça vaut le coup d'examiner. Les constructions sur mesure peuvent être une forme très coûteuse de procrastination.to avoid making a harder business decision, that's worth examining. Custom builds can be a very expensive form of procrastination.
---
L'approche hybride (souvent le mouvement le plus intelligent)
Voilà ce que personne ne dit assez : construire et acheter ne s'excluent pas mutuellement.
L'approche la plus pragmatique que j'aie vue fonctionner régulièrement est celle-ci -- achetez les pièces de commodité agressivement, et construisez la fine couche de logique différenciée par-dessus. Votre CRM est HubSpot. Votre support est Intercom. Mais le moteur de flux de travail sur mesure qui les connecte et automatise votre processus spécifique ? C'est deux semaines de développement personnalisé, pas six mois.
Chez Seahawk, nous avons construit des centaines de sites sur WordPress -- une plateforme achetée -- avec des plugins personnalisés qui font des choses genuinely novatrices. La plateforme gère les 80%. Nous construisons les 20% qui importent. C'est un conseil ennuyeux. C'est aussi le conseil qui a fonctionné le plus souvent.WordPress -- a bought platform -- with custom plugins that do genuinely novel things. The platform handles the 80%. We build the 20% that matters. It's boring advice. It's also the advice that's worked most often.
---
FAQ
Comment sais-je si mon cas d'usage est vraiment assez unique pour justifier une construction custom ?
Réponse honnête : la plupart ne le justifient pas. Commencez en passant un après-midi sérieux -- je veux dire quatre ou cinq heures, pas vingt minutes -- en mappant chaque produit SaaS de votre catégorie. Si vous avez fait ça et rien ne couvre votre besoin fondamental, demandez-vous si ce besoin est vraiment nécessaire en ce moment ou si c'est un bien qui vous semble souhaitable que vous avez élevé en bloqueur. Si c'est vraiment nécessaire et vraiment non-desservi, c'est un signal qui mérite d'être pris au sérieux.necessary right now or whether it's a nice-to-have you've elevated into a blocker. If it's truly necessary and truly unserved, that's a signal worth taking seriously.
Quelle est l'équipe minimale dont vous avez besoin pour posséder responsablement un logiciel custom ?
Au minimum : un développeur qui comprend le codebase en profondeur, et soit un deuxième développeur soit une agence retenue qui peuvent assurer quand il est indisponible. Posséder un logiciel personnalisé avec un seul freelancer et sans secours est une position fragile. J'ai vu ça causer de vrais dégâts opérationnels quand cette personne devient indisponible -- vacances, maladie, une meilleure offre d'emploi.
Devrais-je développer en interne ou engager une agence pour construire du sur mesure ?
Cela dépend presque entièrement de si le logiciel est votre cœur de métier. Si vous êtes une entreprise de logiciels, vous voudrez presque certainement une équipe interne à terme, même si vous commencez par une agence. Si le logiciel est un outil qui soutient votre activité plutôt que l'activité elle-même, une relation avec une agence assortie d'un vrai SLA est généralement plus rentable que d'embaucher des ingénieurs à temps plein.
L'open-source est-il une voie intermédiaire entre construire et acheter ?
Oui, et c'est sous-utilisé. Des outils comme Metabase pour l'analytique, Directus pour un CMS headless, ou ERPNext pour les opérations vous donnent la flexibilité d'un logiciel personnalisé avec un coût initial de build significativement inférieur. Le piège : vous possédez toujours l'infrastructure et vous avez toujours besoin de quelqu'un de technique pour la gérer. Ce n'est pas gratuit -- c'est juste moins cher au démarrage.Metabase for analytics, Directus for headless CMS, or ERPNext for operations give you the flexibility of custom software with significantly lower initial build cost. The catch: you're still owning infrastructure and you still need someone technical to manage it. It's not free -- it's just cheaper to start.
---
Une Dernière Réflexion
La question construire ou acheter n'a pas une réponse. Elle a ta réponse, spécifique à ton stade, ton équipe, ta position compétitive, et ce que tu as réellement validé jusqu'à présent.your answer, specific to your stage, your team, your competitive position, and what you've actually validated so far.
Ce sur quoi je reviendrais est le romantisme autour de la construction. Un logiciel personnalisé n'est pas intrinsèquement plus sérieux, plus scalable, ou plus impressionnant qu'une pile SaaS bien configurée. Le fondateur de facturation que j'ai mentionné au début ? Il a finalement construit quelque chose genuinely personnalisé -- mais seulement après dix-huit mois d'utilisation d'Invoice Ninja qui lui ont enseigné exactement ce dont ses clients avaient réellement besoin. La construction était meilleure pour l'attente.
Commencez par l'option ennuyeuse. Gagnez le droit de construire quelque chose de nouveau.