All companies in this space start out fast and user friendly, but to gain additional customers in this space they need to add more features. See my first item. Then they either fail or end up an uber-platform. Again, this has nothing to do with your company, it is just the nature of the market, and it's funny when someone gets an idea to start a "lean", "fast" product as if no one else had thought of that before.

Really if you think you can do better than X, whether X is oracle forms or SAP or whatnot, it's important to understand where X went wrong. Hint: it's very rarely because they were "old-fashioned" or didn't realize that customers liked fast software that was easy to use. The founders of X were just as smart/capable as you are, but they faced a market challenge and made some choices with trade offs. If you limit your analysis to "they didn't know software should be fast", then you are not going to end up any better than they are once you reach their scale. I am not trying to say that every incumbent always made the right choices. But an understanding of where they went wrong needs to go beyond "they went wrong because they are old fashioned" or "they went wrong because they didn't realize software shouldn't be filled with bugs". There are real hard problems here that need to be understood before you are in a position to improve on what the incumbents are doing.

My general advice is not so much about the software as controlling your corporate appetite for customization. There is just an incredible cost to bespoke customization, while the use cases of it are often things like executives' vanity at getting live dashboards or something else. You can have an in-house team build some forms atop a database, and you can even make that work, but only if you rigidly fight feature creep. If you can't fight the feature creep, might as well go with one of the big solutions so that features are reflected in bottom line costs and have to explicitly be paid for out of your business budget, rather than implemented by making requests of your in-house dev team.

Fix the business processes first or you risk codifying bad business processes in the platform.

Yes. Hire an architect with a proven track record and significant experience and give them the responsibility. Reading a few medium articles or an O’Reily book won’t be a substitute.

I worked in a startup in the B2B space a while back, and it's amazing how much big customers can push you around and demand features. The salesguys would promise something and then a week later we'd have the feature in a special patch build for them. I heard Cisco did the same thing, and by the time they got big they had hundreds of special branches for different groups of customers. It was a mess.

Then I worked for a couple of big B2B companies (currently work for one) and it's basically the same thing except that two weeks becomes 6 months. But given how small the market is, you are still doing customization to drive deals. I think a big part of the appeal of developing these frameworks is so your own support staff can add the feature in without changing the core code. I'd imagine this would be the case for all the big B2B players. No way do any of these companies survive just selling off the shelf, and I have some admiration for the support guys that parachute into Penn State or the Foo Department of Bar or Nestle and help manage a whole massive deployment or roll out some brand new feature. They are working nights and weekends and I'm sure there's a lot of good war stories there.

Unless there is a product designed for the specific needs of their industry, then the 80% of their needs covered by a generic system still means 20% of their needs are in fact oh-so-special