Thank you for the thoughts! You're totally right on the potential abuse risk and the laborious work to keep the email server running correctly. Could you elaborate more on the following please?
it's harder to rationalize banning someone who's abusing it if you're using a subscription model
At the same time, I think onetime fee can be a convincing option for a new, not well known yet product. I'm thinking about offering a onetime fee for early adopters and subscription for others, what do you think?
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
My point is that you'll tend to get more backlash from users if you ban someone who has paid for a 'lifetime' license for the service than if you are dealing with a subscription model. Depending on how quickly they get banned and where exactly the transaction happens, you may even owe them a refund if it's not a subscription model.
I'm thinking about offering a onetime fee for early adopters and subscription for others, what do you think?
I think that's largely reasonable, but I'd be careful to put reasonable limits on the one-time fee (IOW, they could have up to some number of individual aliases active at the same time before they have to start paying just like everybody else). I'd also make sure to spell out clearly in the TOS that you make no guarantee that the service will stay online forever, otherwise you may end up in a situation where you're forced to keep maintaining it to support the people who paid the one-time fee.
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
I couldn't really say for certain. Based on what you've described so far, I can see three use cases for this:
Sorting email by To: header. IOW, use emails through your service for everything, and then have each alias get auto-sorted after forwarding. In this area, you're really just competing with address extensions (the part after the '+' in emails like foo+bar@example.com), and most decent providers properly handle those at no cost with zero setup. On top of that, you'd need to handle things specially on your end for this to work (though you probably should go to the trouble of that kind of handling so things are properly traceable by your users and by law enforcement).
Disposable emails for one-time contacts. Lots of competition in this area, but it also doesn't seem to be your main focus, so not much to say (I'd suggest supporting this use case though, it should be easy to do if you've got persistent alias handling already).
Using differing aliases for each individual service you need email for to obfuscate your online footprint. AFAIK, you have little to no competition here. This is the particular angle I'd suggest marketing towards, as many people would love to be harder to track online.
Support the disposable email is indeed an excellent idea and it's quite easy for us, let me put it into our todo list :).
The product corresponds to the third use case. Its main goal is indeed to protect user online identity. If you are interested, could I contact you to send you more details and have your insights on this product?
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
Sure, though I don't know how much more insight I might be able to provide other than the usual reminder for all online services of 'Make sure you're compliant with relevant data handling legislation (GDPR or otherwise).'.
If you want to drop me an email (should be listed in my DEV profile), that's probably going to be easiest for both of us.
Thank you for the thoughts! You're totally right on the potential abuse risk and the laborious work to keep the email server running correctly. Could you elaborate more on the following please?
At the same time, I think onetime fee can be a convincing option for a new, not well known yet product. I'm thinking about offering a onetime fee for early adopters and subscription for others, what do you think?
My point is that you'll tend to get more backlash from users if you ban someone who has paid for a 'lifetime' license for the service than if you are dealing with a subscription model. Depending on how quickly they get banned and where exactly the transaction happens, you may even owe them a refund if it's not a subscription model.
I think that's largely reasonable, but I'd be careful to put reasonable limits on the one-time fee (IOW, they could have up to some number of individual aliases active at the same time before they have to start paying just like everybody else). I'd also make sure to spell out clearly in the TOS that you make no guarantee that the service will stay online forever, otherwise you may end up in a situation where you're forced to keep maintaining it to support the people who paid the one-time fee.
Thanks, I understand the point on the banning now :). And great point on being careful in the TOS, I'll make sure to put it in the TOS!
As a side note, what do you think about the idea itself? Is this a service that might interest people?
I couldn't really say for certain. Based on what you've described so far, I can see three use cases for this:
To:header. IOW, use emails through your service for everything, and then have each alias get auto-sorted after forwarding. In this area, you're really just competing with address extensions (the part after the '+' in emails likefoo+bar@example.com), and most decent providers properly handle those at no cost with zero setup. On top of that, you'd need to handle things specially on your end for this to work (though you probably should go to the trouble of that kind of handling so things are properly traceable by your users and by law enforcement).Support the disposable email is indeed an excellent idea and it's quite easy for us, let me put it into our todo list :).
The product corresponds to the third use case. Its main goal is indeed to protect user online identity. If you are interested, could I contact you to send you more details and have your insights on this product?
Sure, though I don't know how much more insight I might be able to provide other than the usual reminder for all online services of 'Make sure you're compliant with relevant data handling legislation (GDPR or otherwise).'.
If you want to drop me an email (should be listed in my DEV profile), that's probably going to be easiest for both of us.
Okay just sent you an email :).