Why did you put a transparent address on your free2z profile? If you used a unified address or shielded address then I could send messages and funds to that address. I would rarely if ever donate to a t-address unless there is some cool reason for the transparency.
On free2z you can buy 2Zs with Zcash that can be used for a bunch of things, you can comment with Zcash, send messages and ZEC to shielded addresses p2p. We implemented polls and goals using viewing keys. As one of the only people who has apparently ever implemented long-standing automation with shielded ZEC payments, I can tell you that it’s not ready for something like scooter rental at scale. We need to take incremental steps towards building the tools for bigger consumer-facing ideas rather than shoot for the consumer-facing ideas directly.
Here’s an analogy. We have some people and some hand tools. There is a huge mountain full of precious metals. We could send a few people to the mountain with hand tools to pick away at it. But, a better approach would be to work to improve our tools and our plan. One of the main tools is going away - zcashd. So, it doesn’t make sense to send a couple of people to the mountain with this old hand tool.
Maybe people have questioned the use of the 2Z credit on Free2Z as opposed to synchronous, onchain functions. Wouldn’t it be cooler if everything was onchain? Actually, no. If you were going to implement scooter rental to be paid in Zcash, you would inevitably arrive at a similar system of credits where people could load up a balance ahead of time (with Zcash, other crypto, or fiat) and then instantly use the credits when they want to do something. When actually activating a scooter, people dont want to wait for their wallet to sync, wait for blocks to confirm, etc. Just like when making a comment on a website, people want instant, synchronous, ACID functionality that they are accustomed to.
It makes me think of a new idea: renting scooters with 2Zs 
. Really, you need a traditional database with secure user accounts, a system to buy credits (with Zcash), an API, a UI ,… rebuilding all of that generic functionality is a lot more work than people like to think. But, prove me and other doubters wrong! Do it onchain and spark an instant automation from a ZEC payment. I suggest you strip it down to the minimum viable proof of concept though - here is a zebra node, here I send a payment, here is a minimum event triggered in the “real world” - flipping a simple switch based on the amount. What are the scaling challenges?