The best indication that you've made a great tool that solves a real problem is that people actually start using it. But once they do, improvement suggestions and feature requests are sure to start rolling in. Some of them are trivial to implement. Others, however, may send you down the rabbit hole of refactoring the complete code very quickly.
In this session I will demonstrate some techniques that saved me from the refactoring hell more than once and allowed me to incorporate incoming feature requests in record time.
Good planning is key, of course - but what exactly should you plan for? And what criteria should you set for declining a request? Because some of your (internal) customers will not take a simple 'no' for an answer!