Comparer / Distribution
Produit standalone vs embarqué
Même capacité, deux façons de la livrer. Un produit standalone est votre propre app, vers laquelle les utilisateurs viennent ; un produit embarqué est un widget ou un SDK qui vit dans un produit qu'ils utilisent déjà. L'un possède la relation et assure l'acquisition ; l'autre emprunte une audience et cède la surface. Aucun n'est une version au rabais de l'autre — ce sont deux paris différents sur l'endroit où se trouvent déjà vos utilisateurs.
Deux façons de livrer
Où se joue vraiment l'arbitrage
Quand le standalone l'emporte
Lancez votre propre produit quand la relation est l'actif. Si vous devez maîtriser le client, les données et la roadmap — parce que le produit est l'entreprise, et non une fonctionnalité du produit de quelqu'un d'autre — une app standalone est la seule forme qui vous donne les trois. Elle l'emporte quand l'expérience est le facteur de différenciation et ne survivrait pas à son enfermement dans le cadre d'un hôte, et quand vous êtes prêt à gagner votre distribution plutôt qu'à l'emprunter. Le coût est réel : vous développez toute l'app et vous payez pour acquérir chaque utilisateur. En contrepartie, rien dans votre produit ne dépend de l'autorisation d'un hôte.
- 01La relation client et les données doivent vous appartenir, directement
- 02L'expérience est le facteur de différenciation et exige tout l'écran
- 03Vous êtes prêt à construire et à promouvoir une destination, pas une fonctionnalité
- 04Vous voulez maîtriser les prix, la roadmap et le tunnel de bout en bout
Quand l'intégration / whitelabel l'emporte
Intégrez quand vos utilisateurs sont déjà ailleurs. Si la fonctionnalité a plus de valeur comme composant d'un produit existant que comme destination à part entière — une on/off-ramp dans un wallet, une étape de paiement dans une marketplace, un wallet dans un jeu — alors un widget ou un SDK la place devant une audience déjà constituée en quelques jours, sans demander à personne de télécharger une autre app. Elle l'emporte quand la rapidité et la portée comptent plus que la maîtrise du cadre, et quand « invisible, et ça marche » vaut mieux que « à votre marque, mais il fallait venir la chercher ». Le compromis : la surface et une part de l'économie — vous êtes l'invité dans le produit de quelqu'un d'autre.
- 01La fonctionnalité relève d'un autre produit, ce n'est pas une destination
- 02L'audience est déjà réunie quelque part où vous pouvez vous intégrer
- 03La portée et le délai d'accès aux utilisateurs priment sur la maîtrise de toute l'expérience
- 04Whitelabel ou co-branding — être invisible est un atout, pas une perte
Où se place Protocore
Pas besoin de choisir une fois pour toutes. Protocore propose les mêmes capacités dans les deux formes : Ramp est une on/off-ramp que vous pouvez exploiter comme parcours autonome ou intégrer comme widget dans votre produit ; Wallets est un SDK qui vit dans votre app ; et Pay est une app complète que vous exploitez en standalone sous votre marque. Le même cœur sous-tend l'ensemble : une capacité que vous intégrez aujourd'hui et un produit que vous lancez demain partagent un seul ledger et une seule console opérateur. Commencez en intégré pour emprunter une audience, passez en standalone quand la relation vaut d'être maîtrisée — ou faites les deux, sans reconstruire ce qu'il y a dessous.
- 01Ramp fonctionne en standalone ou s'intègre en widget — même cœur dans les deux cas
- 02Wallets est un SDK qui vit dans votre app, les clés ne quittent jamais l'appareil
- 03Pay est une app standalone complète à votre marque, sur le même ledger
- 04Intégrez maintenant, lancez votre propre produit plus tard, sans refonte
Standalone, intégré, ou les deux ?
Dites-nous où sont déjà vos utilisateurs et ce que vous devez maîtriser. Nous vous aiderons à choisir la forme — une destination, un widget, ou un peu des deux.