If it's a nice problem to have, don't solve it now
This can also be summarized as &quot;Early on, don&#x27;t be afraid of doing things that don&#x27;t scale&quot;.<p>In this particular example, my &quot;reset password&quot; functionality could be sending me an email, and I have to reset the password manually and email you a temporary one that you can use. Bad solution? Yes. Doesn&#x27;t scale? Of course. But if you have 5 customers it&#x27;s not a big deal and you can use your time on something else.<p>The key here is to have good people in the team. A decent Senior Engineer &#x2F; Architect would know that &#x27;Reset password&#x27; will be needed. That is why a very technically solid person is gold in the first round, because they can design the signup in such a way that it&#x27;s prepared for future requirements. They of course would also know that you can&#x27;t store in plain text, that it should be hashed, that you might have to use a vault, that you need to randomize the hash, and that in the future limit access to the &quot;user&quot; table and never ever expose it through an endpoint where a user can reach it, as well as protecting against XSS and SQL injections.<p>Which of the list above goes off the list? There is a balance there in getting the right solution without scope creep, but also not implementing something so silly that it&#x27;s going to get you into trouble later. The genius of a competent person is being able to tell what needs to be solved now vs. later