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.

Estimer le périmètre avec le calculateur

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.

Méthode

Quatre étapes, scope fixe, prix convenu à l’avance.

  1. 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.

  2. 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 ».

  3. 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.

  4. 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.

  5. 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.

Le déroulé complet, les garanties et les prix →

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.

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.