Bien choisir les langages, frameworks et outils utilisés est capital à la fois pour être efficace et rapide. Aujourd'hui je vous présente la stack que j'envisage pour ce projet.
Pour rappel, je suis en train de créer un SaaS en maximum 100 jours. Pour en savoir plus sur les raisons de ce challenge, ça se passe dans le Jour 0, et pour comprendre le projet que je suis en train de développer, rendez-vous en Jour 1.
L'important selon moi lorsqu'on se lance dans la création d'un projet SaaS en solo, est d'utiliser des technos déjà bien maîtrisées. Si vous partez sur un langage ou framework que vous ne connaissez pas encore, le risque est grand de:
J'opte donc toujours pour une techno que je connais, et pour des framework actifs avec une grande communauté et qui permettent de développer très rapidement.
Je suis depuis toujours un grand fan de PHP et depuis plusieurs années un grand fan de Laravel. C'est pour moi le framework idéal car il permet de démarrer très rapidement un projet, avec plein de fonctionnalités déjà prévues et une grande communauté, avec beaucoup de packages disponibles.
Au delà de ça je suis également partisan du server-side rendering plutôt qu'un site de type SPA avec un rendu généré côté client. Je suis personnellement beaucoup plus rapide pour développer de cette manière que si je dois développer une API + une app frontend. La raison est simple: je n'ai pas assez d'expérience dans un framework frontend, donc ce n'est clairement pas la piste que j'utilise lorsque je développe un SaaS. Mais si c'est là-dedans que vous avez de l'expérience, alors c'est la solution la mieux adaptée pour vous.
Oui, jQuery est sans doute un peu vieillot et pas du tout à la mode. Pourtant je l'utilise depuis des années et c'est suffisant pour la plupart de mes besoins, je n'ai donc pas de raison d'utiliser autre chose (hormis si je veux tester et découvrir de nouvelles choses, mais ce n'est pas mon objectif ici).
J'utilise aussi parfois un peu de AlpineJs. Alors oui c'est un tout nouveau petit framework, mais il est utilisé par les composants frontend que je compte prendre, donc je m'adapte et je l'ai trouvé assez pratique dans certains cas d'utilisation.
Mon choix se porte toujours vers les bases de données relationnelles. Je travaille également sur le côté avec mongoDB mais je trouve cela beaucoup trop fouilli et ma préférence va toujours vers le relationnel pour un nouveau projet. Mysql par habitude tout simplement car j'ai déjà passé pas mal de temps à configurer de grosses instances et j'ai donc un peu plus d'expérience qu'avec Postgresql par exemple.
Pour le CSS, j'ai utilisé bootstrap pendant des années, avec grande satisfaction. J'avais pour habitude d'acheter un template sur themeforest pour quelques dizaines d'euros. N'étant pas un développeur frontend, c'était la solution idéale pour moi si je voulais un résultat visuellement acceptable à un bon prix. Petit à petit j'ai commencé à en avoir marre de ces templates fourre tout, utilisant des dizaines de plugins et qui finalement étaient assez difficile à 'nettoyer'. L'année passée j'ai switché pour utiliser Tailwindcss et plus particulièrement TailwindUI. Le prix de TailwindUI peut paraitre élevé, environ 200€ pour l'accès à tous les composants, mais je pense que c'est le meilleur investissement que j'ai pu faire ces dernières années. Grâce à tous ces composants prêts à l'emploi j'y ai gagné énormément en productivité et mes designs sont beaucoup plus homogènes. Et la license autorise l'utilisation sur un nombre illimité de projets pour tout type d'utilisation, donc dans mon cas, c'est bien rentabilisé. Ce nouveau SaaS sera en fait le 5ème projet que je développe avec TailwindUI, et pour rien au monde je n'utiliserais autre chose !
A priori j'aurai pas mal d'emails transactionnels à envoyer (pour les confirmations de participation et le jour de sortie), j'ai donc regardé un peu quelle plateforme j'allais pouvoir utiliser.
Pour Spotontrack, j'utilise Sendinblue mais même si j'adore leur interface (et l'historique illimité), j'ai souvent eu des problèmes avec des emails qui partent avec 30 minutes de retard. Dans certains cas ce ne serait pas bien grave, mais quand il s'agit d'un email de reset password ou confirmation de compte, l'utilisateur n'a pas envie d'attendre 30 minutes. Le problème se produit fréquemment mais ils prétendent toujours qu'il s'agit d'un problème temporaire et ne veulent pas apporter de solution, je ne vais donc plus chez eux pour mes prochains projets.
Mandrill (partie transactionnelle de Mailchimp) coûte 20$ par 25k mails, soit 0.8$ / 1000 mails si on consomme bien tout le quota (qui expire chaque mois).
Sendgrid coûte 15$ / mois pour 40k mails soit 0.4$ / 1000 mails si on consomme tout le quota.
Postmark coute 10$ / mois pour 10k mails, soit 1$ / 1000 mails si on consomme tout le quota.
Mailgun coûte 0.8$ / 1000 mails en pay-as-you-go ou ça revient un peu moins cher en abonnement mensuel.
Amazon SES coûte 0.1$ / 1000 mails, et on ne paie que ce qu'on consomme. A voir si en réalité le prix n'est pas un peu plus élevé car il faudra probablement également payer pour avoir les webhooks (pour savoir les mails ouverts/cliqués).
Clairement Amazon SES semble le plus avantageux, et c'est ce que je vais essayer d'utiliser. L'intégration est normalement prévue de base dans Laravel donc ça devrait bien se passer. Si ça se passe mal, je ne perdrai pas trop de temps et partirai sur Sendgrid, que j'ai déjà utilisé plusieurs fois.
Pour gérer les paiements, j'ai eu l'occasion de travailler avec Braintree sur Spotontrack, et avec Gumroad pour PlaylistSearch. Les deux répondent en fait à un besoin un peu différent. Braintree ou Stripe permettent de prendre des paiements par carte de crédit, mais c'est à vous de calculer les différentes taxes (en particulier la TVA), à éditer les factures et faire toutes les déclarations nécessaires, ... Gumroad a une approche différente et agit en fait comme revendeur de votre produit. C'est donc lui qui vend le produit à l'utilisateur final et se charge donc de collecter la TVA, faire les différentes déclarations etc. De votre point de vue, vous avez un seul client, Gumroad, qui vous paie chaque semaine. C'est donc beaucoup plus simple à gérer. Même si cela a un coût plus élevé, je pense que s'enlever cet énorme travail administratif vaut bien les quelques % de frais de transaction en plus.
Dans le cadre de ce projet, j'aimerais donc utiliser Paddle, plateforme similaire à Gumroad mais qui permet une meilleure intégration via son API et propose plus de fonctionnalités. De plus, Laravel propose une extension pour gérer les paiements avec Paddle, et même pour gérer tout ce qui concerne les subscriptions: Cashier. Quand je vous disais que bien choisir son framework était important 😉
J'ai envisagé quelques secondes d'utiliser Spark (un billing portal payant, développé par Laravel) mais finalement je me conteterai de Cashier pour me permettre une meilleure personnalisation et ne pas me retrouver bloqué aux fonctionnalité de Spark.
L'inconvénient avec Paddle est qu'il faut passer par une étape de validation, et pour valider le compte, ils ont besoin d'un site web en ligne. Mais impossible d'avoir un compte de test pour les développements avant d'avoir un compte validé, donc on a un peu le serpent qui se mord la queue. Je vais développer la landing page au plus vite, en espérant que ça suffira pour leur validation.
Si jamais ça venait à mal se passer avec Paddle, le plan B serait d'utiliser Gumroad. Dans ce cas mon pricing passerait en $ et non pas en €, et je serais donc un peu perdant (ou bien je devrais augmenter le tarif, chose que je ne compte pas faire).
EDIT: depuis l'écriture de cet article, Paddle a lancé 'Paddle Sandbox'. On peut donc maintenant avoir un compte de test avant de passer l'étape de validation par leur équipe.
Pour les déploiements, je vais au plus simple. Pas question d'aller vers le serverless à la mode, même si ça pourrait avoir un intérêt dans ce projet, pour la simple raison que je ne maîtrise pas du tout. Je pourrais regarder du côté de Vapor (déploiement serverless sur aws pour Laravel, développé encore une fois par l'équipe Laravel) dans le futur si nécessaire.
Pour le moment, ce sera donc un simple VPS chez OVH qui contiendra la DB, le apache ou nginx, php, ... Pas de load balancer, pas de master-slave, ... Simple et efficace, on améliorera dans le futur quand ce sera nécessaire. Inutile d'être scalable tant que ce n'est pas nécessaire.
Voilà qui clôture la partie préparation du projet. Il est maintenant temps de se mettre à coder. Rendez-vous dans quelques jours, avec la Landing Page.
Abonnez-vous à pour recevoir toutes les infos chaque semaine.