@ido @jeiden
I cannot say what was the thought process here, but one thing that I imagine I would do to see if a feature is being used or not is go check how many times was it used in the past month, year and then make a decision.
However, one thing that has to be put on the table here as well is: what happens if the feature was used 5 times by 5 customers last year BUT the feature is a recovery mechanism (like a password reset)?
Why do I say this? A password reset is not something you do every day, week, month, or even year.
Maybe when Amazon forces me every 6 months I begrudgingly change the password, or when my employer requests this change every 3 months, well, I have no choice.
But we are talking an IoT product here. How many times would a user want to change their password on their garage opener? On their spa? Zero maybe?
So, if the metric of hits per yea was the main deciding point, I would add, for next time, the dimension of how many times it is supposed to be used by the end customers.
My moral of the story is this: I can't deprecate a recovery mechanism based only on it NOT being used too much in the past years since at the end is only that, a recovery or emergency mechanism that one would need to get out of a situation in case of an emergency.
A cheap analogy comes to mind: imagine a school bus removing the emergency exit because it was not used in the last 5 years.
You can now safely ignore this. I felt like writing it not to complain but in the hopes to offer another view at this and perhaps help in future decisions.
I'm already in the middle of implementing the back end changes needed for this and it is going to look even better than before, BUT at the cost of more work.
I'll tell you why is better than before for future reference:
1- I can now control the look and feel of the email the user receives.
2- The product I'm working with in this case has wifi and cellular options. Having a customer created in both (a wifi Particle cloud product for the photons, a cellular one for the Electrons), meant that for the password reset flow the customer would receive two identical password reset emails as I explain on this topic.
All the best!
Gustavo.
PS: I am using the Firebase Auth feature to implement this on my side.