Bye-bye Superwall, Pourquoi j'ai quitté le SaaS #1 des paywalls
J’ai un aveu : j’ai utilisé Superwall pendant des mois. Et Superwall, c’est bien. Vraiment. C’est le SaaS #1 pour créer des paywalls mobiles sans écrire une ligne de code. Dashboard propre, A/B testing intégré, analytics, le tout.
Sauf que j’ai quitté. Pas parce que le produit est mauvais. Parce qu’il ne correspond pas à ma réalité.
Voici pourquoi.
Ce qu’est Superwall (pour ceux qui vivent sous une pierre)
Superwall est un service qui te permet de créer, modifier et tester tes paywalls sans repasser par le store. Tu changes le copy, les couleurs, le prix, l’offre, tout depuis un dashboard web. Pas de nouvelle version à soumettre, pas de review Apple/Google.
Pour une startup avec une seule app et une équipe dédiée growth, c’est un outil de guerre. Tu itères sur tes paywalls aussi vite que tu changes de slide sur un pitch deck.
Le problème ? Je ne suis pas une startup. Je suis un studio d’apps.
Le cauchemar du multi-app
Quand tu as une app, Superwall brille. Quand tu en as cinq, six, sept, c’est ingérable.
Chaque app a son propre paywall. Chaque paywall a ses propres variations. Chaque variation a ses propres metrics. Le dashboard devient un labyrinthe. Tu passes plus de temps à naviguer entre les projets qu’à optimiser quoi que ce soit.
Ça devient cognitivement lourd de switcher de contexte entre les apps, de se rappeler quelle variation est active où. La maintenance est multipliée : un changement de branding ou de pricing strategy doit être répliqué partout. Et le coût cumulé, quand chaque app a son propre abonnement Superwall, la facture monte vite.
En tant que solo dev, chaque minute passée à gérer des dashboards est une minute volée à shipper. Et le pire ? Je n’ai jamais eu l’occasion de payer. La version gratuite suffisait, ce qui prouve bien que le volume de modifications n’était pas là pour justifier l’investissement.
Si tu n’es pas prêt à payer, c’est que le produit ne t’apporte pas assez de valeur. Point barre.
L’expérience native est meilleure
C’est un fait qu’on oublie souvent : un paywall natif, codé dans l’app, offre une expérience supérieure à un paywall chargé depuis le web.
Pas de loading, pas de cache à gérer, pas de fallback si le serveur est down. Mêmes animations, mêmes transitions, même feel que le reste de l’app. Chaque pixel, chaque interaction, chaque timing est sous ton contrôle. Et ça fonctionne sans connexion, pas de “paywall indisponible”.
Superwall compense avec du caching et du pré-chargement, mais c’est toujours une couche d’abstraction supplémentaire entre ton utilisateur et ton offre. En Flutter, construire un paywall natif prend quelques heures, une fois. Après, tu dupliques le pattern sur chaque app.
Le game changer : les agents IA
Mais le vrai déclic, c’est l’arrivée des agents IA dans mon workflow. Avant, la promesse de Superwall était claire : modifier un paywall sans dev = gagner du temps. Aujourd’hui ? Un agent IA fait tout ça en natif.
Ce que Superwall te vend via un dashboard, mes agents IA le font directement dans le code. “Génère 3 versions du paywall avec des CTA différents” prend 30 secondes. Les variations sont dans l’app, le routing se fait côté client avec Firebase Remote Config. Les événements sont dans Analytics, l’agent lit les résultats et ajuste. Et l’agent peut attribuer une page de vente spécifique selon le profil utilisateur : nouveau, actif, churné, power user.
Avant, il fallait un growth hacker. Aujourd’hui, il suffit d’un prompt.
La boucle est complète : l’agent crée, les utilisateurs voient, l’agent analyse, l’agent itère. Sans dashboard. Sans SaaS intermédiaire. Sans abonnement.
Pourquoi Superwall reste pertinent (mais pas pour moi)
Je ne crache pas sur Superwall. C’est un excellent produit. Mais sa cible, ce sont les startups :
| Startup | Studio d’apps (moi) | |
|---|---|---|
| Nombre d’apps | 1 (la leur) | 5-10+ |
| Équipe | Growth designer dédié | Solo dev |
| Priorité | Optimiser LA conversion | Shipper vite sur TOUTES les apps |
| Budget | $200-500/mois justifié | Facture cumulative ingérable |
| Volume de tests | 10-20 variations/semaine | 1-2 par mois, max |
| Compétence dev | Growth marketer ≠ dev | Dev full-stack = je peux coder natif |
Superwall a du sens quand une personne dédiée passe sa journée à optimiser les paywalls. Quand c’est toi, le dev, le marketeur, le designer, le support, et que tu gères 7 apps, le ROI s’effondre.
La direction que Superwall devrait prendre ? Plus d’IA générative intégrée. Des agents qui proposent des variations, formulent des hypothèses, segmentent les utilisateurs automatiquement. S’ils le font, ils pourraient devenir pertinents pour les indie devs. Mais pour l’instant, leur value prop reste : “un humain derrière le dashboard.” Et moi, je n’ai pas d’humain à y mettre.
Ce que j’ai à la place
Mon setup actuel est 100% natif, 100% agent-powered.
Flutter + Clean Architecture pour un composant paywall réutilisable, dupliqué par app. Firebase Remote Config pour le routing des variations côté client. Les agents IA pour la génération de variations, l’analyse des résultats, les suggestions d’itération. Et Analytics natif : events, funnels, cohortes, le tout dans Firebase/GA4.
Résultat ? Zéro abonnement externe, expérience native parfaite, et un agent qui fait le travail d’un growth hacker pour une fraction du coût.
Le SaaS parfait, c’est celui que tu n’as pas besoin d’utiliser.
Le verdict
Bye-bye Superwall. Pas par haine. Par pragmatisme.
Superwall est un excellent outil pour les startups qui ont une app et une équipe growth. Pour un studio d’apps géré par un solo dev qui code en natif et utilise des agents IA, c’est une couche de complexité inutile.
L’expérience native est meilleure. Les agents IA comblent le fossé entre “il faut un dev” et “il faut un dashboard.” Et quand tu multiplies les apps, chaque outil externe que tu supprimes est une victoire.
Si tu es solo dev avec plusieurs apps, pose-toi la question : est-ce que cet outil me fait gagner du temps, ou est-ce qu’il me donne l’illusion du contrôle ? Si la réponse est la deuxième, le mal est fait. Code natif. Avance.
Si tu kiffes ce genre de retours d’expérience indie dev, abonne-toi à la newsletter. Je partage chaque semaine mes décisions produits, mes erreurs et mes apprentissages.