Avant même de coder : comment je pose les fondations de mon SaaS Portfolio & Risk Tracker

Quand on parle d’un nouveau SaaS, on montre généralement une interface, des écrans, des fonctionnalités.
Dans mon cas, le projet n’a encore presque rien : une simple page d’accueil Next.js côté front, et quelques projets F# créés avec dotnet new côté backend.

Et pourtant, c’est précisément maintenant que les décisions les plus importantes ont été prises.

Cet article raconte comment j’ai posé les fondations du Portfolio & Risk Tracker, un SaaS centré sur le suivi de portefeuille et l’analyse du risque.
Pas en présentant des fonctionnalités, mais en expliquant ma démarche, car elle fait partie intégrante du rôle de Tech Lead : construire avant de coder.

1. Commencer par le “Pourquoi”

Avant le choix des technologies, avant les migrations, avant la première route HTTP, j’ai pris le temps de clarifier pourquoi je voulais construire ce projet.

Le point de départ est simple :
je voulais un outil pour suivre mes investissements de manière claire, lisible, et compréhensible.
Sans Excel fragile, sans outils trop complexes, sans jargon.

À cela s'ajoute une ambition réaliste :
proposer une version freemium, avec assez de valeur pour être utile dès la partie gratuite,
puis des fonctionnalités premium autour du risque, de l’analyse et de la projection.

Ce “pourquoi” m’a permis de définir :

le public cible,
la vision long terme,
ce qui doit être fait maintenant… et ce qui peut attendre,
comment éviter de partir dans tous les sens dès le début.

2. L’architecture avant la codebase

Avant d’écrire le moindre fichier .fs ou .tsx, j’ai défini la structure suivante :

un domaine métier en F#,
une API en C#,
un front en Next.js 15/16,
un monorepo pour faciliter la cohérence du code et l'onboarding.

Ce découpage n’est pas là pour faire “joli”.
Il répond à trois objectifs :

Simplicité

Le domaine reste indépendant.
L’API reste remplaçable.
Le front peut évoluer sans casser le reste.

Testabilité

Le cœur métier en F# est parfait pour construire des règles pures, testables, et composables.

Évolutivité

Je ne sais pas encore comment le SaaS grandira.
Mais je veux qu'il soit simple de :

migrer l’API vers gRPC,
ajouter une deuxième application plus tard,
isoler certaines parties si le produit scale.

3. Pourquoi F# pour le domaine ?

Le Portfolio & Risk Tracker manipule des règles financières, des calculs, des transformations, des pipelines métier.
C’est exactement ce que F# fait extrêmement bien.

Quelques raisons de mon choix :

expressivité du domaine,
absence d’accidents de null,
composition naturelle (|>),
Result / Option intégrés,
code plus court, plus clair, plus robuste.

Ce n’est pas un choix “exotique”.
C’est un choix pragmatique, aligné avec le type de logique que manipulera le projet.

4. Pourquoi C# pour l’API ?

F# est excellent pour le domaine, mais pour l’exposition HTTP,
C# reste un standard robuste :

outillage mature,
documentation abondante,
intégration naturelle ASP.NET Core,
future compatibilité gRPC,
adoption facile si une équipe rejoint le projet.

F# + C# n’est pas une séparation complexe.
C’est une spécialisation naturelle :
F# pour dire ce que fait le métier, C# pour exposer ce métier proprement.

5. Next.js 15/16, Tailwind et shadcn : une base moderne pour le front

Pour l’interface, je voulais une solution :

moderne,
performante (RSC, App Router),
facile à internationaliser,
compatible avec une UX propre,
et capable d’accueillir un designer.

Next.js 15/16 s’est imposé naturellement.
Avec TailwindCSS et shadcn/ui, j’ai une base qui me permet :

de prototyper rapidement,
de rester cohérent visuellement,
de gérer le dark mode,
d’assurer une bonne ergonomie responsive,
d’être prêt pour la montée en qualité quand j’intégrerai un designer.

6. La base de données : Neon pour commencer, mais sans se figer

Pour démarrer, j’ai choisi Neon, un Postgres serverless moderne, pratique et économique.

Mais ce choix n’est pas définitif.
Selon l’évolution du SaaS, je peux tout aussi bien passer à :

Azure Postgres,
Supabase,
Render,
ou une instance managée classique.

L’important n’était pas de trouver “le meilleur système” dès le premier jour,
mais d’adopter un modèle facilement migrable.
En utilisant un Postgres standard, je garde cette liberté.

J’ai également découpé la base en plusieurs schémas (prt, auth, billing)
pour préparer l’arrivée de fonctionnalités premium et d’une éventuelle architecture multi-tenant plus tard.

7. Monorepo, multi-repo, mono-tenant, multi-tenant : une hésitation légitime

Comme n'importe quel Tech Lead qui prépare un SaaS, j’ai réfléchi à plusieurs alternatives d’organisation.

Monorepo ou multi-repo ?

Le monorepo simplifie :

l’onboarding,
la cohérence,
les conventions,
les devcontainers.

Le multi-repo, lui, devient intéressant si l’API ou le moteur F# deviennent des produits autonomes.

Pour l’instant, j’ai choisi la simplicité :
un monorepo — mais une architecture pensée pour évoluer si nécessaire.

Mono-tenant ou multi-tenant ?

Le MVP démarrera en mono-tenant, plus simple techniquement.
Mais j’ai structuré le schéma de données et le domaine F#
pour pouvoir basculer vers du multi-tenant sans réécrire tout le projet.

8. Devcontainer : penser équipe, même en étant seul

Je pourrais travailler “à la main”.
Mais un devcontainer me donne :

un environnement reproductible,
la même configuration partout,
une base partagée front + back,
une intégration propre avec Codespaces.

Même si je suis seul pour le moment,
je prépare déjà un projet dans lequel un designer ou un autre développeur
peut arriver sans se battre avec la configuration.

C’est un gain de temps futur qui vaut toujours l’investissement présent.

9. Une roadmap réaliste : avancer par incréments

Plutôt que de viser trop large, j’ai découpé le projet en trois étapes :

1. MVP

ajout d’actifs,
affichage du portefeuille,
performance simple.

2. Analyse du risque

volatilité simplifiée,
risque par actif,
risque global.

3. Premium

projections,
alertes,
analyses avancées,
exports.

Ce découpage évite l’effet tunnel,
et permet d’avancer vite sans mettre en péril l’architecture long terme.

10. Avant la première feature, agir en Tech Lead

Ce que j’ai fait jusqu’ici n’est pas du “code”.
C’est de l’ingénierie.

Un SaaS ne commence pas par un écran.
Il commence par :

un cadre,
une architecture,
un environnement propre,
une vision,
des choix assumés,
des hésitations réfléchies,
une base solide.

C’est cette phase invisible que je voulais documenter,
car elle représente une part essentielle de ma manière de travailler.

Conclusion — Le projet n’a presque rien, mais il tient déjà debout

Aujourd’hui, Portfolio & Risk Tracker n’a aucune fonctionnalité visible.
Mais il possède :

une vision claire,
une architecture saine,
un domaine F# structuré,
une API prête à évoluer,
un front moderne,
un environnement reproductible,
des choix techniques argumentés,
une roadmap réaliste.

Le code arrivera ensuite.
Les fondations sont là.

Dans les prochaines semaines, je publierai d’autres articles pour aller plus en profondeur sur certains choix :
le domaine métier en F#, le devcontainer multi-stack, ou encore l’évolution possible vers une architecture multi-tenant.

Le SaaS commence à peine, mais la structure est en place.
Et c’est souvent la partie la plus importante.