curious about the business side of this solution. How do you envision onboarding & integration of a new game vs an existing game? A web game vs a locally-hosted game?
I'm curious what the vision for the "setup" process looks like and at what point does it become do-it-yourself instead of shepherded by Customer Success?
Thank your for the question! For us there is no difference between an existing game or a new game, we are even able to onboard ios , android and PlayStation/ console games as long as they are using a database, which 99% do. Why should games go with us? We provide a ready to go solution which provides allready 99% of the needed web3 work. So the game doesnt need to invest in blockchain devs, no need to touch, modify and maybe break their existing game mechanics and security. But overall, they dont turn a web2 game into a web3 game, both, web2 gamers can remain as web2 gamers and can use, if they want, all the benefits of blockchain. Why does project relay on external bridges/ cex / dex if they could do by their own? Cause they do not have the knowledge/ funds or they prefer perfect solutions.
Can you rephrase the second part please ?
For now, the setup process will be guided. We want fully tested and properly integrated game on our platform that understand their role in maintaining their part of the API. If a game's API endpoint go down, our user's will have a poor or unstable experience, which is not in our platform's best interest.
So it sounds like initially, the setup & maintenance process will be very technically-oriented and require dedicated oversight on the customer's side. Sorta like using a raw API endpoint that they decide how/when to use. Is that on the right track? The motivation of my 2nd question is around 1) the cost of servicing a customer, 2) the path to value realization for a customer, and 3) the path of autonomy/self-sufficiency for a customer.
Обсуждают сегодня