Récemment

pour repartir sur une autre aventure, en tant que Indie Hacker/solopreneur (appelez ça comme vous voulez).

J'ai plusieurs projets qui sont sortis progressivement des cartons ces derniers mois :

• un moteur de blog statique opensource utilisant Nuxt et Nuxt-content, qui me permet notamment de faire ce blog

Et j'ai deux SAAS en préparation, pas encore totalement sortis :

• TubeTally.com, pas encore public, un outil d'analytics pour Youtube
• RssFeedPulse, un SAAS pour créer des newsletters à partir de flux RSS, idéal pour les blogs statiques.

Le second est proche de l'ouverture publique. Je l'utilise déjà pour moi et si vous vous inscrivez à la newsletter de ce site, vous l'utiliserez indirectement.

Chacun de ces projets a été construit en moins d'une semaine.

Mais, si on exclut la chaine Youtube, il y a une grosse différence entre "construire" un projet, et le rendre publique.
Il y a un monde entre développer un produit, et en vivre.

Déjà avant de développer :

• comment on choisit de travailler sur une idée ?
• Comment on choisit un nom de produit ?
• Comment on définit son modèle de prix

Et une fois que le produit est développé

• Comment on trouve un nom de domaine ?
• Qu'est-ce qu'on met dans les pages "légales" du site ?
• Comment on collecte les paiements, avec quel soft ?
• Comment on facture ?

Je ne vais pas tout traiter dans cet article, d'autant que certains sujets sont toujours en cours. Mais, si ça vous intéresse, je vais beaucoup en parler sur ce blog dans les prochains mois, alors restez à l'écoute (abonnement newsletter, toussa toussa).

Par contre aujourd'hui je peux vous parler de la stack technique que j'ai décidé d'utiliser.

Mes contraintes

Avant de parler de la stack, petit rappel de ma contrainte principale : l'argent, et j'inclus le temps (parce que le temps c'est de l'argent ^^)

Une stack technique pour moi ça doit être :

• facile à déployer (pas de temps à perdre)
• peu couteuse en RUN (RUN = tourner en production)
• productive, c'est-à-dire que mon expérience développeur doit me permettre de développer très rapidement

Sur un SAAS, je cherche à éviter le "Hype driven developement", donc pas ou peu de nouvelles technos qui brillent et qu'il faut apprendre en même temps que je créé le produit.

Malgré tout, l'écosystème permettant de faire tourner des applis front ayant pas mal évolué ces dernières années, je me suis permis une petite entorse à cette règle en évaluant l'usage de Supabase.

L'architecture générale

L'architecture générale, c'est-à-dire quelles sont les grandes technos que je vais utiliser et comment elles vont communiquer entre elles, est l'un des choix principaux qui vont conditionner le type d'hébergement ensuite, donc le cout et les services qu'il faudra ajouter pour que tout marche.

Prenons un exemple.

J'ai hésité à utiliser Nuxt-Hub pour déployer une app full stack dans le Edge.
Alors, ça fait beaucoup de mot compliqué. Je vais clarifier.

Avec Nuxt, on peut déployer une application avec un frontend, et une partie backend (des apis par exemple), entièrement sur le edge. Le edge, c'est, un peu comme un CDN, un serveur très proche de l'utilisateur. Le edge c'est en général peu couteux et c'est performant.

Cloudflare propose pas mal de service en edge, notamment une base de données, c'est du SQLite et le cout est très, très compétitif.

Une alternative serait d'utiliser Supabase. Supabase propose également une base de données, du postgresql cette fois-ci, mais également tout un écosystème de service, fonction serverless, module d'authentification etc. Le cout est aussi très compétitif. Il est de 0 sur un très généreux free tier. Et il passe ensuite à 25 euros.

J'avoue n'avoir pas été séduit par les possibilités de scheduling (avoir des jobs et des systèmes de workers) des deux architectures ci-dessus.
D'ailleurs sans surprise, il existe des services qui compensent ces faiblesses comme trigger.dev mais, ce sont donc des euros en plus à dépenser.

J'avoue également que l'expérience développeur proposé ne me plait pas (nécessité d'utiliser docker pour supabase, le typage des objets du modèle, et les logs surtout côté serveur !!).

Je suis donc revenu sur une architecture plus standard pour moi :

• une api en kotlin
• un front qui consomme l'api (en Nuxt)
• un contrat openapi entre les deux (rien à voir avec openai !!)

La techno frontend

Côté front, j'ai sans hésiter choisi :

• Nuxt
• Tailwind

Je ne suis pas dev frontend à l'origine mais je me sens particulièrement productif avec ces deux technos. C'est également ce que j'utilise pour Bloggrify (qui propulse ce blog).

Nuxt tourne très bien en SSR (server side rendering), CSR (client side rendering) ou hybride. C'est donc un très bon candidat pour respecter les futures contraintes SEO que j'aurais. L'expérience développeur est très bonne.

La techno backend

La techno backend est plutôt classique, pour moi :

• Kotlin (langage qui tourne sur la JVM)
• Spring Boot
• Postgresql

L'hébergement

J'ai choisi de démarrer avec Clever cloud pour environ 20 balles par mois (16 euros de DB, 5 euros d'application).

Ca a le défaut d'être plus couteux que les free tiers de ces équivalents front, et proposer moins de fonctionnalités (que Vercel, netlify, supabase, cloudflare). Mais, je me sens beaucoup plus à l'aise sur la stack.

(je ne dis pas que ma stack est parfaite, je dis que je suis productif avec, ce qui est très différent)

J'ai écarté des options plus riches, comme cloud run qui m'aurait permis de bénéficier du scaling à 0.
Le scaling à 0 permet de ne consommer aucune ressource quand l'application n'est pas utilisé. Mais Cloud SQL (la base de données managée de GCP) coute beaucoup trop cher. Je ne souhaitais absolument pas gérer ma propre base de données. Ca aurait été possible pour moins de 5 euros avec pas mal d'options. Mais je n'ai aucune envie de gérer ça manuellement.

J'ai considéré des options comme fly.io ou koyeb qui ont du scaling a 0 et ont parfois aussi un prix pour les Bases de données qui différentie compute (le temps d'utilisation) et storage (la taille de la base de données). Mais j'ai été un peu rebuté par un modèle de prix parfois moins lisible, qui semble plus élevé, ou le fait que Java n'était pas directement supporté, il fallait que je créé mon propre container docker.

La stack parfaite

Pour réaliser un SAAS en une semaine, il existe une multitude d'option.
Mais il n'existe pas de stack parfaite.

Sauf si on considère que la stack parfaite, c'est celle dans laquelle vous êtes à l'aise pour créer votre SAAS en une semaine.

La capacité à déployer vite une idée reste primordiale. Il ne faut pas passer des semaines à tester toutes les architectures possibles, évaluer toutes les technos, ou mettre en place des solutions complexes. Avec l'habitude, votre stack devrait vous permettre de mettre une nouvelle app en production en moins de 2 jours (j'inclus le temps de dev).

Et c'est pourquoi je n'ai pas étudié chaque solution, testé chaque provider PAAS. J'ai pris la solution qui paraissait la plus simple/rapide pour l'instant, j'y reviendrais peut-être par la suite. Mieux vaut une mauvaise décision rapide qu'une bonne décision lente.