Issues with maintaining member registers

One major area I’m super excited about when it comes to the development of the co-op passport is solving problems with maintaining member registers.

Resonate’s development history is a great use-case showing how the passport could be a fundamental technology for maintaining non-local member registries.

In 2015, being a website developer by trade, I started a basic WordPress-based directory on the website, showcasing the artists that wanted to join the initiative. This then led to our first crowd campaign and this is where the struggles started:

  • First, we had a directory based in WordPress, with artists, labels, volunteers and of course listeners.
  • Next, we did a crowd campaign on a brand new platform. All sales (memberships and supporter shares) were tracked there, which resulted in a bunch of spreadsheets at the end of the campaign.
  • Supporter shares then had to be manually entered back on the wordpress site. Since we now had some funds to build our first player (but not enough for a full platform) that meant that we continued to build out the wordpress-based directory and profile/identity system.
  • We also moved on-going signups and share purchases back into the wordpress site, soon after the crowd-campaign concluded.
  • That meant a great deal of work reconciling original purchases (memberships and shares) from the crowd campaign with the expanding wordpress-based site.

Bit of a mess, huh?

It got even worse in that some of the custom code for our first music player was also used for displaying those shares in listener profiles. (Can’t remember how many times I wrote a variation of “don’t worry, your shares are duly recorded even if they’re not displaying properly in your profile”.)

So of course, when I think about the kinds of features that the passport will provide I get super excited:

  • a solid system of KYC (co-op member identification and verification)
  • cryptographically signed transaction logs
  • a design in which member status is extracted from development databases

This last point is key, because most startups go through multiple versions of their overall systems as they grow, so having a tool like this that sort of “sits outside” of the member system being built would, IMHO be enormously beneficial to all new platformcoops.

Definitely a lot more to be built to support this vision, but there’s a solid foundation to do that important work. Excited that this is coming to fruition!


Great write up! Yes, I’m particularly excited about mutualising KYC costs. They’re one of the biggest hidden costs of running a co-op I think.