You are allowed to keep some data for cases like financial stuff etc, not sure on specifics as there are quite a few national privacy laws these days (California's one, GDPR, UK's GDPR, South Africa's POPIA).

The approach to zero out data and anonymise as much as possible is sound - I've done it before for dayjob stuff. It's useful because metrics don't get skewed by data going missing.

Interesting, in my view it's not very much text ha!

I'd like to dig in a bit more if you don't mind: I suppose the view on the amount of text content depends on the purpose of it in your and my view - do you suggest very minimal text to give it more of a "straight to the point" kind of vibe or something else? From my perspective I'm trying to keep it a bit light while still establishing some authority with the customer, and be clear on exactly what they're getting. So it's not exactly a heavy sales page but also not a one-click everything.

On point 3, it will be useful for Hey to contain its own explainers and how it benefits the usage of Hey (or other benefits in general). "Go read over here" doesn't provide the necessary context on your own app in relation to the protocol, which is what is missing here. In other words, I'd say the same thing whether it was Lens, ActivityPub, or any other protocol: users need to see it through the lens (haha) of your app.

First thought: Knowing nothing about the Lens Protocol, why would I use this?

In other words, are you gearing this towards people already in the dapp space or more generally?

Here's my first revision: ns2024test2.carrd.co/

• Clearer product delineation & more detailed descriptions
• Straight to the point
• Pricing in EUR (might change to USD, it's more dependent on which kind of clients I'd like to get)
• Consolidated some of the offerings

Ideas for refinement:
- One thing I'm toying with is potentially trying to ditch calls from the offers altogether - at least, reduce the need for them as much as possible.
- An introduction video from me

Thanks for the feedback! Will definitely move the blocks around a bit.

To be clear, this is explicitly not the same model as DesignJoy. I think he's actually corrupted the "productized service" term a bit, because not all productized services are just subscriptions. See here, as I'm following Jonathan Stark's description: jonathanstark.com/fps

Under that definition, tiers/plans are not applicable. The offering as I'm exploring it is selling individual tasks directly, and that's what the offering list reflects.

Ha, discovery is a side of communities I've explicitly avoided because it's such a hard problem. What I've been able to find is directory sites for communities that are often tied to a specific tech. E.g. Slofile for Slack groups, and another site I forget now for discovering Discord communities.

I wonder if this idea of doubling down on the personalised touch & network graph extends for discovery as well? In my mind that's the only real way to bypass it. Otherwise you become tied to the platforms. And just because Slack and Discord aren't Facebook, it doesn't mean one is much safer in the end in terms of control and not getting arbitrarily banned.

I run a tech meetup/community myself: PHP South Africa. I've had discussions with many other meetup hosts about Meetup.com being such a horrible platform, but they all give me the same answer in return: "yes it sucks, but it's where everyone is, so yeah I'll shell out the $120 a year just to post events."

If people do succeed without these discovery mechanisms and go purely off of the tactics we've discussed, that's also not necessarily a scalable/automatable approach, like you say. So building SaaS for that might be tricky. Perhaps there's tools/features that can be added to ease that work, at least?

This is very insightful, thanks!

You mention reaching out directly into groups, creating communities, appearing in guest blogs and podcasts, and listing in directories - this is kind of what I've had in mind as the potential longer term alternative here. Being intentional and posting in ultra-relevant niche communities and making direct connections with others. I.e. going back to a personalised network/social graph to deliver value (and get customers!) instead of the interest graph that has been forced on us for engagement.

I liken it to focusing on being a medium fish in many small ponds, than trying to be a gigantic fish in an entire ocean. There's a lot more food that way!

That way, you can also focus on controlling the network more. Specifically with things like email lists instead of followers. Longer term when there's budget (for tech) or time to manage it, owning the tech of your community is also beneficial since no one can take it down (within legal bounds I mean) when you run your own forum and newsletter infrastructure.

Jason Leow's latest post seems to agree! Saw it on the WIP feed now.

golifelog.com/posts/new-indie…

It's not a bad option, sure, but you have to be explicit about it. Is it purely to get a bit of support for the content, or do you intend to use this as a revenue stream? In the former case you have to be clear that what they're doing is supporting you with no guarantee of any return. In the latter you're usually offering something exclusive in return for these Patrons.

What I've also seen done are "just support" Patreon tiers at something like $1 that gives no benefits, or alternatively also open a BuyMeACoffee/Ko-Fi/etc account alongside Patreon for one-off donations.