Développement SaaS · Suisse
Développeur SaaS en Suisse.
Je conçois et construis des produits SaaS en Suisse, de l’architecture au déploiement : authentification, rôles et permissions, modèle de données Postgres, paiements et abonnements Stripe, emails transactionnels, tableaux de bord, interface d’administration, analytics et mise en production. Une seule personne, du repo vide à la première version qui tient face à un vrai client.
Mis à jour le
En bref
- Où
- Zürich, Suisse — à distance dans toute la Suisse et en Europe
- Format
- Forfait — un seul prix, convenu avant de commencer
- Délai type
- 4 à 6 semaines pour un v1 prêt pour un premier client
- Fourchette
- CHF 20’000 – 45’000 pour un v1 de SaaS, selon le périmètre
- Stack
- Next.js · TypeScript · Postgres · Stripe · Resend · Vercel
- Construits et exploités
- Atamatax · Horvera · Wabiro (en production) · SponsorsMetrics (bêta privée)
Un SaaS n’est pas un site avec un login. C’est un système : des comptes, des données qui appartiennent à quelqu’un, de l’argent qui circule, des emails qui doivent partir, des erreurs qui doivent être visibles avant que le client ne les voie. Ce que je livre, c’est ce système — pas une maquette qui y ressemble.
Je travaille depuis Zürich avec des fondateurs et des PME de toute la Suisse et d’Europe, en français et en anglais. Le format est toujours le même : un appel de cadrage, une proposition forfaitaire, un sprint de 4 à 6 semaines avec une démo chaque vendredi, puis le hand-off complet — repo, comptes, pipeline.
01 — Périmètre
Ce que comprend le développement d’un SaaS
Les briques qu’un produit SaaS doit avoir le jour où quelqu’un paie pour s’en servir. Je les construis toutes ; le périmètre décide lesquelles sont nécessaires pour votre v1.
- Authentification et sessions
- Email + mot de passe, lien magique ou OAuth selon l’audience. Sessions côté serveur, réinitialisation, vérification d’email, protection contre la force brute.
- Rôles et permissions
- Propriétaire, membre, admin, lecture seule — modélisés dans la base, appliqués côté serveur, jamais seulement masqués dans l’interface.
- Modèle de données
- Un schéma Postgres posé en premier : entités, relations, contraintes, index, migrations versionnées. C’est la partie la plus chère à refaire plus tard, donc la première que je stabilise.
- Paiements et abonnements
- Stripe Checkout ou Billing, webhooks signés, états d’abonnement synchronisés en base, factures, échecs de paiement, essais et changements de plan.
- Emails transactionnels
- Bienvenue, confirmation, reçus, alertes, rappels — envoyés via Resend depuis un domaine vérifié, avec des templates React Email et un journal des envois.
- Tableaux de bord et exports
- Les écrans où le client vit tous les jours : listes filtrables, détails, actions en masse, export CSV. Rendus côté serveur, rapides, sans état fantôme.
- Interface d’administration
- Votre back-office : voir un compte, rembourser, désactiver, corriger une donnée, comprendre ce qui s’est passé. Sans ça, le support se fait en SQL.
- API et intégrations
- Endpoints typés, validation Zod, clés d’API si des tiers doivent lire vos données, connecteurs vers les services que vos clients utilisent déjà.
- Analytics et observabilité
- Événements produit (PostHog ou Vercel Analytics), logs structurés, alertes d’erreur, journal d’audit sur les actions sensibles.
- Sécurité et conformité
- Validation côté serveur partout, limitation de débit, secrets hors du code, données scopées par compte, conformité nLPD / RGPD par conception.
- Déploiement et exploitation
- Vercel, previews par branche, migrations en pipeline, sauvegardes, variables d’environnement documentées — et le tout vous appartient.
02 — Vocabulaire
Prototype, MVP, v1, SaaS en production : quatre objets différents
Les quatre mots circulent comme des synonymes. Ils décrivent quatre niveaux d’exigence — et quatre budgets.
- Prototype
- Démontre une idée. Peut être branlant sous le capot, personne ne va y vivre. Utile pour lever, tester, convaincre. À jeter ensuite — ne jamais le « finir ».
- MVP
- Mot-valise. Pour les uns un prototype poli, pour les autres un v1 réduit. La seule question utile : un vrai client peut-il s’en servir et payer sans que vous interveniez à la main ?
- V1
- La première version qui survit à son premier client : auth, données solides, paiements réels, emails, erreurs gérées, admin. C’est ce que je construis — voir le développement d’un v1 de SaaS.
- SaaS en production
- Le v1 plus ce que la vie réelle ajoute : monitoring, sauvegardes testées, exports, rate limits, support outillé, conformité, chemins de récupération. Une partie se construit dès le v1, le reste au fil des vrais clients.
La différence entre ces niveaux n’est pas le nombre d’écrans mais ce qui se passe quand quelque chose ne marche pas. Un prototype qui casse fait rire ; un v1 qui casse perd un client. J’ai détaillé la distinction dans Prototype ou v1.
03 — Architecture
Comment j’architecture un SaaS
Le modèle de données d’abord. Avant tout écran, je pose le schéma Postgres : quelles entités existent, à qui elles appartiennent, ce qui est immuable, ce qui est versionné. Un SaaS dont les données sont bien posées se laisse faire évoluer ; un SaaS dont l’interface est belle et les données floues se réécrit.
Ensuite l’application : Next.js avec l’App Router, composants serveur par défaut, server actions pour les formulaires, routes API seulement quand un tiers doit appeler le système (webhooks Stripe, intégrations). TypeScript strict de bout en bout, validation Zod à chaque frontière.
La logique métier vit dans des modules purs, testables, versionnés — pas dans les composants. Sur Horvera, le moteur d’éligibilité est un ensemble de règles versionnées qui produit chaque réponse avec sa trace et ses sources ; sur Atamatax, le moteur de situation fiscale mappe des faits vers des formulaires en montrant ses hypothèses. Le même principe s’applique à une facturation à l’usage ou à un calcul de commission.
Les paiements passent par Stripe avec des webhooks signés ; l’état de facturation est en base, jamais déduit côté client. Les emails partent via Resend depuis un domaine vérifié. Le déploiement est sur Vercel avec une preview par branche — c’est sur ces previews que se font les démos du vendredi. Le détail est dans Architecture Next.js pour un SaaS en production.
04 — Coût et délai
Ce que coûte le développement d’un SaaS en Suisse
Un v1 de SaaS construit correctement se situe en général entre CHF 20’000 et 45’000, au forfait. En bas de la fourchette : un périmètre serré — authentification, un flux principal, paiements, déploiement. En haut : plusieurs rôles, une logique métier dense, des intégrations tierces, un tableau de bord de données. Trois choses font bouger le prix : la complexité du modèle de données, le nombre d’intégrations, le niveau de finition attendu.
Le délai type est de 4 à 6 semaines de sprint après l’appel de cadrage et la proposition. Le prix est fixé avant de commencer et ne bouge pas ; si j’ai mal estimé, c’est mon problème, pas votre facture. La mécanique complète est dans Combien coûte le développement d’un v1 de SaaS en Suisse, et le calculateur de coût SaaS vous donne une bande de complexité en cinq minutes.
Cinq minutes. Une bande de complexité, pas un devis.
05 — Recruter ?
Recruter un développeur SaaS, ou faire construire le v1 ?
Si le SaaS est votre entreprise, vous aurez besoin d’une équipe : la feuille de route d’un produit vendu ne s’arrête pas. La question est l’ordre. Recruter d’abord, c’est demander au premier ingénieur de construire seul, sans pair pour le juger, pendant les mois où le produit n’a pas encore de clients. Faire construire le v1 d’abord, c’est arriver au recrutement avec un produit, des clients et un code documenté à reprendre.
Ce n’est pas toujours le bon ordre : si votre équipe technique existe déjà, renforcez-la plutôt que d’externaliser. Le guide recruter ou externaliser compare les deux avec le coût employeur réel en Suisse et un outil qui peut vous répondre « recrutez ».
Est-ce le bon service ?
Ce service a du sens si
- Vous avez des signaux réels — une liste d’attente, un client pilote, un investisseur qui regarde — et il vous faut la version qu’on peut leur montrer.
- Votre produit contient une vraie logique métier : règles d’éligibilité, calculs, tarification, workflows à états, permissions fines.
- Vous voulez une seule personne responsable de bout en bout, un prix connu d’avance, et repartir avec le repo et les comptes.
- Vous êtes une PME qui remplace un processus manuel ou un tableur par un produit que des clients paieront.
Ce n’est pas le bon service si
- Vous testez encore l’idée et personne ne va payer cette semaine — un prototype coûte une fraction et c’est ce qu’il vous faut.
- Le produit exige une équipe de trois personnes ou plus dès le départ, ou du temps réel critique (trading, jeu multijoueur).
- Vous cherchez de la régie à l’heure ou un développeur à intégrer dans une équipe existante — je ne travaille pas en staff augmentation.
- Vous voulez apprendre à le construire vous-même — c’est le rôle de la Build School.
Preuves — produits construits et exploités
Mes propres produits, avec leur état réel. Aucun projet client n’est publié à ce jour.
- atamatax.comEn production · paiements actifsAtamatax — l’infrastructure fiscale des Américains à l’étrangerMoteur de situation fiscale, scan PFIC, packages payants avant checkout, export pour comptable — un SaaS à logique réglementaire dense, en production.Next.jsTypeScriptPostgresStripeVercelLire l’étude de cas →
- horvera.comEn production · paiements actifsHorvera — l’infrastructure de l’indemnisation des volsMoteur de règles versionné EU261 / UK261 / CH, Claim Pack payant, parcours de réclamation et d’escalade — logique juridique en production.Next.jsTypeScriptPostgresStripePostHogLire l’étude de cas →
- wabiro.comEn production · paiements actifsWabiro — des tests d’identité et de relation conçus pour la recherche et le partageTests, scoring déterministe versionné, cartes partageables, rapports premium payés via Stripe — un produit grand public à boucle de partage.Next.jsTypeScriptPostgresStripeVercelLire l’étude de cas →
- sponsorsmetrics.comBêta privée · onboarding des design partnersSponsorsMetrics — le cockpit de pricing pour agents de talents YouTubeBenchmark CPM, deal desk, rapports vérifiés via l’API YouTube Analytics en OAuth lecture seule — un SaaS B2B analytique.Next.jsTypeScriptPostgresYouTube APIVercelLire l’étude de cas →
Méthode
Quatre étapes, scope fixe, prix convenu à l’avance.
- 01
Diagnostic
20 minutes, gratuit. Modèle économique, workflows, risques, périmètre produit. Si je ne suis pas la bonne personne, je le dis.
- 02
Architecture et proposition
Sous 48h : modèle de données, frontières du système, intégrations, UX — et un seul prix forfaitaire avec des jalons datés. Pas de « à partir de ».
- 03
Construction
4 à 6 semaines d’itérations contrôlées. Démo chaque vendredi sur une preview Vercel. Vous voyez le système grandir en direct — pas de boîte noire.
- 04
Mise en production
Paiements, analytics, déploiement, workflows opérationnels. Vous repartez avec le repo, les comptes, le pipeline — et 30 jours de réponses sous 24h.
- 05
Amélioration
Itération mesurée sur l’usage réel : un nouveau forfait par périmètre, ou rien si votre équipe reprend. Pas de dépendance cachée.
Questions fréquentes
Combien coûte le développement d’un SaaS en Suisse ?
Un v1 de SaaS construit correctement coûte en général entre CHF 20’000 et 45’000 au forfait. Le bas de la fourchette correspond à un périmètre serré (auth, un flux principal, paiements, déploiement) ; le haut à plusieurs rôles, une logique métier dense et des intégrations. Le prix est fixé avant de commencer.
Combien de temps faut-il pour construire un v1 de SaaS ?
Quatre à six semaines de sprint pour un v1 prêt pour un premier client, avec une démo chaque vendredi sur une preview. Le cadrage et la proposition prennent une semaine avant cela.
Quelle est la différence entre un MVP et un v1 en production ?
Un MVP peut encore dépendre de vous pour fonctionner — une donnée corrigée à la main, un paiement vérifié par email. Un v1 en production tient seul : authentification, paiements réels, emails, erreurs gérées, interface d’administration. C’est cette version que je construis.
Freelance ou agence pour développer un SaaS ?
Une agence apporte une équipe et un compte-rendu ; vous payez aussi la coordination et le turnover. Un développeur indépendant senior porte l’architecture et le code lui-même, au forfait, avec un seul interlocuteur. Pour un v1 de SaaS, la seconde option coûte moins et va plus vite — tant que le produit tient dans les mains d’une personne. Voir Freelance ou agence web en Suisse.
Quelle stack pour un SaaS moderne ?
Next.js (App Router) avec TypeScript, Postgres pour les données, Stripe pour les paiements, Resend pour les emails transactionnels, Vercel pour le déploiement. Supabase quand il faut une auth et un stockage gérés rapidement. C’est la stack de mes propres produits.
À qui appartient le code ?
À vous. Le repo, les comptes Vercel, Stripe, Resend et la base de données sont créés à votre nom ou transférés au hand-off, avec la documentation des variables d’environnement et du pipeline.
Que se passe-t-il après la livraison ?
Trente jours de réponses sous 24h sont inclus. Au-delà, un nouveau forfait pour la suite — ou rien, si votre équipe reprend. Le produit est construit pour être repris : pas de dépendance cachée à moi.
Pour aller plus loin
- Combien coûte le développement d’un v1 de SaaS en Suisse ?Le vrai prix d’une première version, sans le « ça dépend » — et pourquoi le forfait bat la facture horaire.Ingénierie SaaS6 minLire →
- Prototype ou v1 : la différence qui décide de votre lancementUn prototype impressionne en démo. Un v1 survit au premier vrai client. Confondre les deux coûte cher.Construire un produit5 minLire →
- Architecture Next.js pour un SaaS en production : les décisions que je prends sur chaque produitCe qui sépare un projet Next.js qui tient de celui qu’on réécrit au bout d’un an tient à une dizaine de décisions. Voici les miennes, telles qu’elles sont appliquées sur Atamatax, Horvera, Wabiro, SponsorsMetrics — et sur ce site.Next.js & full-stack9 minLire →
- Freelance ou agence web en Suisse : quelle est la différence, et comment choisir ?Une comparaison honnête sur dix dimensions — coût, communication, capacité, redondance, risque de livraison — puis le cas où ni l’un ni l’autre n’est la bonne réponse.Construire un produit9 minLire →
Autres services
- Développement v1 SaaSLa première version qui survit à son premier client — ce qu’elle doit contenir, et ce qu’on peut laisser pour plus tard.
- Refonte d’applicationReconstruire un produit qui a vieilli, ou un prototype devenu trop fragile, autour de son modèle métier — données migrées, bascule sans interruption.
- Développeur Next.jsDes applications Next.js en production — App Router, composants serveur, Postgres, Stripe — rapides, indexables, maintenables.
Vous avez un SaaS à construire ?
Écrivez-moi en une ligne ce que le produit doit faire le jour où le premier client paie. Appel de cadrage de 20 minutes, gratuit, proposition sous 48h.
danilson.daveigaramos.pro@gmail.com · Réponse sous 24h, du lundi au vendredi.