----
My biggest pain isn't with the plan. It's with the actual upgrade process. Things _always_ break. Every single time we do a major upgrade, there's this long tail of things we need to fix. Even worse is the undocumented changes that break. This gives me nightmares.
The problem with your product is four parts:
* It needs to solve much more of the problem. It's not really valuable to know that I need to change stuff. I can figure that out by running my package managers update tool and seeing what breaks.
* When things break, it's unbelievably time consuming to fix them. Even worse is the person tasked with doing the upgrade is likely not the subject matter expert on broken code.
* I need to know what's broken that wasn't documented. This is by far the hardest part of our upgrade cycles. It keeps me up at night knowing a major upgrade could break things that aren't covered by unit tests.
* Because dependency upgrades are so hard, we tend to do them in large swoops. We set aside a week or two of pain and power through them. Given you're charging $60/m, this suggests:
* Your model is more aligned with small, continuous upgrades. Once you're "close" to the most recent version, it tends to be easier to upgrade.
* Your model needs a better way to "gain pace" with the latest releases. If I can incrementally upgrade one package on every PR until I'm up to date, that'd be amazing.
I think this tool would be extremely value to me (likely $60/m/repo) if it:
* It ran the repo's test suite against progressively newer versions of dependencies. Showing when and where unit tests fail.
* Provide some means of "intelligent E2E" testing. Fire up our API/application. Tell us what changes when dependencies are upgraded.
* Fan out broken code to the subject matter expert. If an upgrade from X to Y is broken, look at the `git blame` to figure out who knows how to fix the code. Ping them asking them for help.