> If you decide to do in-house, I’d recommend thinking about competing against existing as a new revenue stream, and spinning it off as a separate business unit as much as possible.
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.
+1. Last startup I worked at basically tore itself apart because certain leaders fantasized about spinning of "AWS for X" before we had even met our own needs.
On this point it’s worth noting that internal users are very very different from external users too.
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.
You’re both correct. Absolutely you need to start small and build confidence over time. However, it’s important to know early if you plan to eventually make the product a profit center. You can establish legal and technical foundations that will make your life much easier down the road.
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.