Our biggest month of growth came from deleting code not from writing code.
by•
We spent three months building a team‑permissions dashboard because five vocal users asked for it strongly. That dashboard made our entire settings UI cluttered and confusing for everyone
I saw activation rates for signups drop right away. New users felt overwhelmed by the toggles before they even tried the core product.
We ripped the custom permissions system out and returned to simple admin/member roles. support tickets fell by half. The product felt noticeably lighter.. Those five vocal users? Three of them had not even logged in to use the feature they had asked for.
We always think the answer to a problem is to build a feature. How do we decide when it is time to remove something of fixing it?
14 views
Replies
If you have user data, I think it’s best to make decisions based on it, just as you did with your service.
As our user base has grown, I also want to start removing code for features that look cool but no one actually uses.