Solutions / SaaS
Créez un véritable SaaS, pas une démonstration
Multi-locataire dès la première table, offres et utilisation mesurée dès le premier checkout, gates de fonctionnalités que la facturation garde honnêtes. Décrivez votre produit — Kliv construit autour de lui la mécanique de niveau entreprise.
Les arguments en faveur de sa construction
Pourquoi construire ceci au lieu d’assembler la stack ?
La méthode par défaut pour créer un SaaS est l’assemblage : un fournisseur d’authentification, un SDK de facturation, une base de données, un service de messagerie, un outil d’indicateur de fonctionnalités — cinq fournisseurs avant la première ligne de votre produit réel. Les liens entre eux deviennent votre base de code : les gestionnaires de webhooks réconciliant la facturation avec l’accès, les tâches de synchronisation copiant les utilisateurs entre les systèmes et la classe de bugs de 2 heures du matin où le fournisseur de facturation dit payé et l’app dit verrouillée. Kliv expédie le châssis comme un seul système (tenancy, facturation, droits d’accès, e-mail, données), de sorte que les coutures que vous auriez passé des mois à écrire n’existent pas.
Le châssis est indifférencié ; votre produit ne l’est pas. Personne ne choisit votre app pour sa page de connexion ou ses e-mails de facture, même si une version cassée les fera partir. Consacrez la description à votre domaine, ce que vous seul connaissez, et laissez les pièces communes à tous les SaaS arriver déjà composées. Lorsque votre tarification change (un nouveau niveau, un add-on limité, une offre d’entreprise), il s’agit d’une phrase dans une conversation, pas d’une réarchitecture.
Anatomie du système
De quoi est réellement fait un SaaS
Supprimez le produit et chaque SaaS a le même squelette : locataires, sièges, offres, portails, compteurs, factures. Kliv expédie le squelette ; vous décrivez le produit qui l’entoure. Voici ce que le système sait dès le premier jour.
Organisations
Chaque client est une organisation : ses utilisateurs, ses données et sa facturation sont réunis dans un même mur. La société A ne peut pas lire la société B dans la base de données.
Membres et rôles
Vos clients sont des entreprises, pas des identifiants : des propriétaires, des administrateurs et des membres, chacun voyant ce que son rôle lui permet.
Offres et tarifs
Le catalogue : niveaux, essais, déblocages uniques, add-ons mesurés – votre page de tarification en tant que données appliquées par le système.
droits d’accès
Le lien entre l’argent et les fonctionnalités — ce que l’abonnement de cette organisation ouvre, vérifié partout où cela compte.
Compteurs et consommation
L’utilisation est comptabilisée dans l’activité de connexion du client — visible pour lui et facturable par vous.
Abonnements & factures
L’état commercial de chaque locataire — en test, actif, en souffrance — avec les factures le justifiant.
Qui voit quoi
Règles appliquées par la base de données
- Les lignes d’un locataire appartiennent au locataire : les lectures inter-organisations sont impossibles au niveau de la base de données et ne sont pas filtrées dans l’app.
- Les droits d’accès suivent la facturation en temps réel : un passage à une offre supérieure ouvre les fonctionnalités maintenant, une annulation les réduit dans les délais.
- Le compteur et la facture sont le même système : ce qui a été mesuré est ce qui est facturé, sans rien à rapprocher.
- Un paiement échoué commence la relance (nouvelles tentatives et e-mails de récupération) avant qu’un verrou ne se ferme sur un client payant.
C’est la partie d’un SaaS que personne n’a choisi de construire et que tout le monde doit construire : l’identité, le multi-tenant, l’argent et les règles qui les lient. Lorsqu’il s’agit d’un système unique, votre description concerne votre produit.
Les parties difficiles du SaaS, déjà résolues
Ce ne sont pas des add-ons — ce sont les mêmes éléments de plateforme, composés.
Multi-tenant par défaut
Lorsque les clients s’inscrivent à votre app, chacun obtient sa propre organisation. L’entreprise A ne peut jamais voir les données de l’entreprise B : l’isolation est appliquée à chaque requête au niveau de la base de données, et non dans le code d’app que quelqu’un doit penser à écrire. Vos propres données d’administration se trouvent derrière un mur séparé, uniquement interne.
Équipes et sièges à l’intérieur de votre produit
Vos clients ne sont pas des utilisateurs uniques, ce sont des entreprises. La connexion, les rôles et le partage par organisation font partie du même système d’identité, donc « tout le monde dans la même entreprise voit les projets de son entreprise » est une phrase, pas un sprint.
Facturez comme le SaaS facture réellement
Abonnements avec essais et prorata équitable, déblocages uniques et tarification à l’usage avec compteurs. « Une offre Pro à 20 USD par mois, plus 2 c par rapport généré » est une description : Kliv crée les produits, les prix et les compteurs pour vous.
Des fonctionnalités qui suivent l’argent
Attachez des fonctionnalités aux offres et verrouillez pages, données et fonctionnalités avec elles. Passage à une offre supérieure, passage à une offre inférieure ou annulation : l’accès suit automatiquement dès que la facturation change. Pas de code d’accès, pas de synchronisation nocturne.
Vendez également l’accès au contenu
Le stockage de fichiers intégré possède ses propres règles d’accès : privé, partagé par organisation ou derrière un abonnement. Les PDF, vidéos et téléchargements Premium se débloquent avec les mêmes droits d’accès que le reste de votre app.
Facturation en libre-service, dans votre app
Les clients mettent à jour leurs cartes, changent d’offre et lisent les factures sur une page de facturation à l’intérieur de votre produit. Lorsqu’un paiement échoue, Kliv le réessaye et leur envoie un e-mail jusqu’à ce qu’il soit récupéré.
Façons de facturer
Trois façons dont un SaaS peut facturer
Les pages de tarification évoluent : les niveaux sont divisés, les compteurs apparaissent, une transaction d’entreprise nécessite une facture. Le catalogue doit suivre le rythme sans réarchitecture.
Abonnement à plusieurs niveaux
29 USD à 99 USD/mois
L’équipe choisissant Starter ou Pro
Niveaux de fonctionnalités attachés aux offres : Starter obtient le noyau, Pro ouvre le reporting, l’API, les fonctionnalités d’équipe.
- Déverrouille
- Les fonctionnalités suivent l’offre : un passage à une offre supérieure les ouvre immédiatement, un passage à une offre inférieure les réduit dans les délais, rien ne change manuellement.
- Facturation
- Mensuel ou annuel avec essais et juste prorata ; les cartes ayant échoué reçoivent des tentatives et des e-mails de récupération avant que l’accès ne soit restreint.
- Remboursements
- Approuvé — un remboursement est une décision, pas un accident.
Basé sur l’utilisation
0,05 USD par course
Le client dont la facture doit suivre sa valeur
Une offre de base plus un compteur : rendus, messages, appels API — quelle que soit l’unité de valeur de votre produit.
- Déverrouille
- L’utilisation est comptabilisée dans l’activité de connexion du client, visible sur sa page de facturation avant l’arrivée de la facture.
- Facturation
- Les frais de compteur s’accumulent et sont facturés au cours du cycle de l’abonnement : le compteur et la facture concordent car il s’agit du même système.
- Remboursements
- Les éléments de campagne contestés sont résolus via le même processus d’approbation.
Déverrouillage unique
500 USD une fois
Le client qui souhaite l’add-on, pas un autre abonnement
Un module à vie, un package d’intégration, une offre d’adoption anticipée — vendus une fois, à côté des abonnements.
- Déverrouille
- L’achat accorde un droit permanent qui coexiste avec l’offre utilisée par le client.
- Facturation
- Un frais, un reçu : même catalogue, même page de facturation.
- Remboursements
- Le même flux soumis à approbation.
Avant le lancement
La première semaine, avant le lancement
Un SaaS a plus de mécanique à éprouver que n’importe quel site vitrine — c’est exactement pourquoi la première semaine compte.
Façonner le produit
Décrivez-le : ce que fait le produit, qui est un client, les niveaux et ce que chacun ouvre. Kliv crée le premier aperçu avec des organisations, des offres et des verrous déjà réels.
Faites-le vôtre
Votre domaine, votre marque, la langue de votre produit et une page de tarification générée à partir du même catalogue que celui appliqué par le paiement.
Connecter le réel
Connectez Stripe, définissez les prix réels et la durée des essais, attachez des fonctionnalités aux offres et invitez votre équipe à accéder à la vue de l’opérateur.
Essayez de le casser
Inscrivez-vous en tant que client test. Essayez de lire les données d’une autre organisation — regardez la base de données refuser. Faites échouer une carte, passez à une offre inférieure, regardez les verrous suivre.
Puis répéter un an
Dans la Sandbox, avec de l’argent et du temps simulés, exécutez la première année de votre SaaS avant le lancement : les essais se convertissent ou expirent, un client passe à une offre supérieure en mars, une carte échoue en juin puis se récupère, une annulation ferme les bonnes fonctionnalités à la bonne date. Vous publiez une entreprise qui a déjà tourné — au lieu d’espérer qu’elle tiendra.
Construire ou acheter
Pourquoi ne pas simplement coller la stack ensemble ?
| La stack collée | Avec Kliv | |
|---|---|---|
| Multi-tenant | La fonctionnalité d’organisation d’un fournisseur d’authentification ainsi que des filtres de lignes que vous écrivez et révisez pour toujours. | Organisations appliquées au niveau de la base de données : les lectures entre locataires sont impossibles et non filtrées. |
| Facturation ↔ accès | Les gestionnaires de webhook rapprochent le fournisseur de facturation avec l’idée de votre app concernant qui a payé. | Les droits d’accès suivent la facturation de manière native : il n’y a aucun lien à concilier. |
| Tarification d’utilisation | Un service de comptage, un service de facturation et un travail de rapprochement entre eux. | Le compteur et la facture sont le même système. |
| E-mail de cycle de vie | Un autre fournisseur, un autre langage de modèle, un autre webhook. | Reçus, relances et rappels d’essai intégrés à vos modèles. |
| Temps de production | Des mois de châssis avant la première fonctionnalité différenciée. | Le châssis est le premier jour ; votre description est consacrée au produit. |
Multi-tenant
La stack collée: La fonctionnalité d’organisation d’un fournisseur d’authentification ainsi que des filtres de lignes que vous écrivez et révisez pour toujours.
Avec Kliv: Organisations appliquées au niveau de la base de données : les lectures entre locataires sont impossibles et non filtrées.
Facturation ↔ accès
La stack collée: Les gestionnaires de webhook rapprochent le fournisseur de facturation avec l’idée de votre app concernant qui a payé.
Avec Kliv: Les droits d’accès suivent la facturation de manière native : il n’y a aucun lien à concilier.
Tarification d’utilisation
La stack collée: Un service de comptage, un service de facturation et un travail de rapprochement entre eux.
Avec Kliv: Le compteur et la facture sont le même système.
E-mail de cycle de vie
La stack collée: Un autre fournisseur, un autre langage de modèle, un autre webhook.
Avec Kliv: Reçus, relances et rappels d’essai intégrés à vos modèles.
Temps de production
La stack collée: Des mois de châssis avant la première fonctionnalité différenciée.
Avec Kliv: Le châssis est le premier jour ; votre description est consacrée au produit.
Questions courantes
Comment l’isolement des locataires est-il concrètement appliqué ?
Au niveau de la base de données, avec des règles au niveau des lignes. Chaque client est une organisation et leurs lignes portent cette limite : un bug dans une page ne peut pas divulguer les données d’un autre locataire, car la requête elle-même revient vide.
Puis-je combiner un abonnement avec une consommation mesurée ?
Oui, c’est une offre, pas deux systèmes : un niveau Pro avec 0,05 USD par rendu en plus. L’abonnement facture la base, le compteur facture l’utilisation et le client voit les deux sur une seule facture.
Que se passe-t-il lorsqu’un client annule ou rétrograde ?
Les droits d’accès se limitent au calendrier défini par votre politique (immédiatement ou à la fin de la période) et les données restent. Un client fidèle reprend son organisation là où elle se trouvait, ce qui fait de sa reconquête un événement de facturation et non une migration.
Les clients peuvent-ils gérer leur propre facturation ?
Oui, une page de facturation dans votre produit : mise à jour des cartes, changement d’offre, lecture des factures. Lorsqu’un paiement échoue, la relance retente le prélèvement et envoie un e-mail au client avant que l’accès de quiconque ne soit restreint.
Puis-je modifier les prix après le lancement ?
Oui, le catalogue est constitué de données. Ajoutez un niveau, divisez une offre, introduisez un compteur ; les nouveaux prix s’appliquent aux nouveaux checkouts et les abonnements existants conservent les conditions qu’ils ont achetées jusqu’à ce que vous en décidiez autrement.
S’agit-il d’une véritable multilocation ou de comptes avec des indicateurs de fonctionnalités ?
Multi-tenant réel : chaque organisation cliente constitue une frontière de premier ordre dans la base de données, avec ses propres utilisateurs, rôles et lignes — la même architecture multi-tenant que celle sur laquelle Kliv s’exécute.
Décrivez votre SaaS. Kliv construit le reste.
Multi-tenant, facturation, droits d’accès et contenu : une plateforme, une conversation.