An internal user that can wander over to Bob and say hey, this thing isn’t working quite right, I’ll grab a coffee with you and we can talk through it, is very different from a paying corporate who will not tolerate service falling below a certain standard. I joined a company where they were trying to transition an internal piece of condition monitoring software to be a SaaS app and it went really badly wrong, the sales people seemed to assume it was ready for this but it just wasn’t and needed a huge amount of hardening and security work, not to mention features to make it easier to use.
There was no market for it, it was too expensive, too unwieldy and too nonstandard.
AWS could do 90% of what the custom cloud product could and the last 10% was regulatory stuff, not technical.
Another option is to consider building in the open. If the technology is not a differentiator in your industry, then maybe you build it open source under GPL. That way you can build a consortium of similar firms to build a genuine alternative to the status quo while preventing lockout.
You don’t have to decide about proprietary vs open source release now… but you should consider taking steps to preserve those options down the line.
That’s taking the second step before the first. If this is going to work at all, first try to build a solution that works for you. Once you have that, then there may be a chance that others will find it useful as well, but it is a whole lot of additional work to turn an in-house solution into a proper product, and your in-house needs are unlikely to translate 1:1 to other companies, and vice versa.