Re-work hosting page #231
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
From Varun:
@hodlbod Happy to take this. The 2+1 structure makes sense — Coracle as the primary path with a clear CTA, self-hosted moved to a secondary section, third-party as a quiet exit link. I'll study the current page and the n8n reference before touching anything. Will post a quick layout sketch before opening a PR if that's helpful.
Hi @hodlbod ,
I was reviewing this issue and the proposed 2+1 layout. I completely agree with the underlying goal: Coracle is the monetization engine, and we absolutely need to optimize the flow to drive its adoption.
However, looking at this from a Product-Led Growth (PLG) and UX perspective, I want to raise a few critical observations before we commit to this specific UI direction. Introducing a payment option or hiding another option during the initial onboarding introduces high friction that might actually hurt our long-term conversions.
Here is what my research indicates:
1. Onboarding Friction & The Activation/Retention Moment
Habit-Building First: Many conventional apps purposefully hide payment visibility at onboarding. They want to make sure that users are habituated and comfortable with the product first. My primary user research reveals that users require some form of core action performed for their first "activation moment" right after onboarding, and the current proposed approach risks blocking that.
Progressive Monetization: In apps like Discord or Slack, monetization is treated as a natural progression. Payment options reveal themselves organically when the user is trying to achieve a feature that lies outside the scope of free usage (e.g., Discord Nitro for file uploads, custom swags, and Slack's 90+ days of history). They don't throw it at the starting options right away.
Avoiding Drop-offs: According to OpenView’s SaaS Benchmarks and NN/g's studies, facing a financial decision before activation leads to extreme drop-off rates (60+%). The monetary and business factors will automatically follow if the end-user experience and product quality are good, but we cannot risk initial trial and payment collection just for a little initial business that makes users drop off in the short term.
The n8n Example: Even in Varun's example of n8n, they don't show pricing on their primary landing funnel. (You have to specifically click on the Pricing button of the navigation panel to view pricing cards). Their core activation flow is:
Landing Page --> "Get Started for Free" Button --> Set up your account --> Start 14-day free trial (without showing any pricing card or financial details requirement upfront ) --> Directly shows you the workflows dashboard and use
2. Product Maturity & Data-Driven Decisions
The 2+1 approach shown is typically followed when product discovery, funnels, and metrics have been established, and a product is mature.
It would make sense if it were backed by data, for example, if data showed us that <5% of our users choose the third hosting option. Hiding the 3rd option might be feasible and might not affect conversions, but since we are still gathering that baseline data, I'd love to validate this assumption before we completely replace the current UI.
I am not saying that we should not explore this approach eventually, but extensive user research and user behavior need to be documented before we make such an important decision on what hosting options to show and hide.
3. Alienating the Nostr-Native Base & FOSS Philosophy
Usually, users switch to FOSS or Web3 because they want to take an advantage over conventional Web2 software. They want to understand every option they have transparently, learn new things, and then decide what is best for them. This is the primary reason for their switch.
Hiding the power option of relays behind a quiet exit link biases heavily toward Coracle and neglects that our pilot phase includes Bitcoin/Nostr native users. In the sights of scaling, we should not lose the advantage of being a transparent communication tool. We should strive for generating revenue from providing value and voluntary customer spend.
Note on Payments: If we are presenting a paid tier to a Web3 demographic, we should also educate users and encourage them to use Bitcoin/Lightning as the payment method, as accepting dollars primarily via conventional methods would go against the Web3 ethos. But at the same time we should always have an option to accept payment in a conventional method aslo aligned with ICPs.
4. Quick note on the UI integration
A Proposed Middle-Ground:
Instead of a hard pricing choice upfront, what if we adopt a true PLG approach?
We can guide users to create a space instantly of their choice, a frictionless free-trial path. Once they are inside, onboarded, and see the value of the platform, we seamlessly introduce the premium Coracle hosting plans versus the self-hosted fallback or relays.
I’d love to do some rapid A/B testing on these two onboarding funnels during our upcoming pilot organizer interviews to see actual user behavior. Then, I will present to you how Coracle becomes the default mental model for users without compromising any factor.
Let me know what you think!
Citations:
I basically agree with all that, but at the same time we have to be pragmatic about getting something done today (we currently have no monetization, and a broken hosting flow). This is just a first pass based on obvious problems, and can be validated/refined later with usability testing. Some notes though:
@hodlbod Just a heads up — I'm down with fever and have end-sem exams April 23–28. I can still take this on but won't be able to start until after the 28th. If that timeline doesn't work for you, happy to hand it off. Just didn't want to sit on it silently.
Thanks for the heads-up! I'll unassign this for now. Hope you feel better soon.
Fixed in
99b26680b6