I would debate that...if your 'product' takes a team of stanford engineers to actually deploy at an enterprise, then it's probably closer to a dev framework.
No, it's a bog-standard on-premise "Enterprise" product, like Oracle, SAP, etc. This is how that business model works. The customer pays _both_ for the software _and_ for the on-site engineers, usually through the nose.
Well, they need a way to get up-to-date data into the system from whatever it's coming from. That alone requires someone to write code. They probably also do some customizing of what data is displayed; maybe via a GUI or maybe via code. But that's just the last mile (on each end) that needs customization.
I don't see how you can simplify that into calling it a "dev framework".
> if your 'product' takes a team of stanford engineers to actually deploy at an enterprise, then it's probably closer to a dev framework
Fair enough. But you may be underestimating the value of production-quality fast-development dev frameworks in enterprise.
Remember, these are guys who are used to seeing 5-year project timelines for anything that touches more than one system. (And every business case touches more than one system...)