twitter.com/jaku

Deploying to another environment with their keys for the 3rd party services like Stripe and others is very easy. Any updates we do for ourselves would be easy enough to add to our own deployment pipeline.

Costs would be a concern if they have a large amount of traffic, since it's deployed on AWS and uses sockets, it could easily pass the free tier. So I'd need to make sure they are aware of that and are paying for the cost of that.

My main concerns come from the support/recognition aspect. If a viewer has a balance of coins in CC and ends up on one of these streams, their balance wouldn't match up since they would be separate systems. So the viewer could be confused there, and the streamer may not be the best at explaining the disconnect. So at the very least, I think having our UI updated to look different is one thing that I'd need our team to do, which would be the most amount of work on this whole thing.

Additionally, from time to time creators and viewers just have issues and our support is very quick at resolving the issues. So, I'd propose a support clause in the white label, but if they don't go for that, then I'd be concerned that viewers may think that it's Crowd Control as a whole.

The streaming community is large but also very small and user experiences matter quite a bit to our reputation/brand.

I'm leaning towards exploring this with the client more and think overall it could be a good thing for us to offer to other agencies that are concerned with revenue share for their creators. But I'll need to try and figure out what makes sense based on their size and expected revenue from this.

This service currently does not require a subscription. We have an add-on that one can subscribe to, but the revenue is mainly made from revenue share. Each effect sent can have a monetary value associated with it, and we make 20% from that.

This agency has around 15 creators under them, so they want to ensure all sales are controlled by their agency. Right now if a viewer bought $100 worth of coins, and didn't spend all of it on the stream, their concern is that the $10-$20 or whatever the viewer has in coins could be spent outside their agency and they think that will be a large potential loss.

Thanks Ben. I don’t think we’d give them the source code in this white label situation, I think we’d even continue to host it so they don’t even get the minified code that’s deployed.

Appreciate your response, it’s certainly different industries but it’s always good to hear about how this worked for others.

In this case, for the other company it’s all about keeping control of the sales/revenue and coins in their creators ecosystem. If a user buys $10 of coins they want the viewer to either not spend it at all thus the coins sit dormant or they are only spent on their creators. That seems like their main reason for this but as I think about it I need to compile a list of things they may need to be aware of with this and have a few different pricing options depending available for them.

Ah! That would do it. I see now, thanks for the clarification.

It's very possible I'm just thinking it will create issues of users with name overlap complaining that their names are not available.

The extra benefit of driving people to sign up early is actually a pretty nice incentive.

Thanks for the feedback.

How does it expose the email address? These names come from the creators' names on platforms like Twitch/Twitter/Discord. So twitch.tv/jaku my link would be mywebsiteservice.com/twitch/j….

I suppose if jaku is part of my email this is true, but they'd have to assume the rest of the email and what provider I'm using to receive email?

Unless I'm missing something here?

Yeah, so we would use the username of the account that is logging in with the OAuth provider that the user picked. The services we use already have a username for the user, which is where our problem basically comes in. Our users are content creators, so they may already have a following under these names, but we know there are some users that might be popular on Twitch with one name, and another user with the same name is popular on TikTok.

In our case, if two users were to log in to our platform and we used their names as an identifier in a URL, that would cause an issue when having them share a link like {domain}/{username} to their userbase.

I see you have Google and Facebook, and you ask for a name on signup but this works differently than what we are looking to do since the username is coming from the provider.

One issue I see with having the name getting set on a first come basis from one provider is that it can then create a domino effect of requiring users to find a new name on login. The first user comes in as Bob from Twitch, and the second user comes in as Bob from TikTok, we then ask TikTok Bob to change their name, so they change it to Tom. Now Tom from Twitch logs in and has to change their name, and even Tom from TikTok has to do the same.

I'm leaning towards a URL structure like {domain}/{service}/{name} so users can keep their names, and users trying to find their creator on our platform might be able to still guess another creator's URL if they already have an existing creator's URL. Just something about including the service in the URL comes across as tacky or weird I guess.

I'm not sure there really is any other solution that can meet my criteria, even if we went with the Discord route and the # didn't cause issues, users wouldn't easily be able to guess their creator's URL.