walletbeat

First Walletbeat planning meeting happened today.
Used @fileverse as notetaking tool, works great! (Who needs G**gle D*cs?)

Main meeting takeaway for me: So many blockers left before launch 🫠

Meeting notes:

Self sovereign stack for collaboration and files creation/management 💛

http://dsheets.new and http://ddocs.new

First Walletbeat planning meeting happened today.
Used @fileverse as notetaking tool, works great! (Who needs G**gle D*cs?)

Main meeting takeaway for me: So many blockers left before launch 🫠

Meeting notes: https://github.com/walletbeat/walletbeat/blob/governance-meeting-20250622/governance/minutes/2025-06-22.md

when thinking about building products, I am now super suspicious if I have an idea that takes more than a few days (even hours!) to ship

anything more ambitious than that probably has a set of "stepping-stone" features that act as intermediate for validation and user acquisition

e.g. @clankfun started as a web page that nicely rendered the output of one Dune API call. launching this got enough attention that validated working on a bump feed, which got enough attention to build in trading, and so on and so on. each step reinforced the value for existing users whilst gaining a new set of users.  I was shipping nearly every day in the first few months, from day 1

The prevailing wisdom on Farcaster is more on the ship-super-quickly-and-iterate-later side of things (https://farcaster.xyz/nt/0xa54a0762).

I find that that's difficult for /walletbeat, because launch means instantly creating implicit "demands" on known external actors (wallet developers). That seems imposing and wrong to do so without a high degree of certainty that those demands are mutually-beneficial, useful, sustainable, reasonable, achievable, applicable, meaningful, fair, and ecosystem-aligned. Which takes time to get to.

The price for getting any of it wrong is the creation of a relationship with wallet development teams that is perceived as fraught and/or adversarial. Not good place to be from the get-go, and it makes future iterations and course-corrections that much harder to do.

(Or perhaps all of the above is just cope, and all projects face such dilemmas?)

Contributor @ /walletbeat.

Censorship resistance requires privacy.

Thanks. Yes, most decisions here (other than UX stuff perhaps) feel higher-stakes than a new opt-in mini-app feature :)

It is more about the context. The name of the game is "Can I afford to make that mistake or have issues related to that feature if I am shipping while the feature is still being developed"

Yes the answer is yes, then yes, shipping early has more benefits.

However, there are cases when the answer is no and we have to accept some things take time to build with sufficient quality to not hurt both your product, your customers and its ecosystem.