> 3) the potential customer sees a small startup team as a risk and are not willing to switch part of their process to an unproven entity.
This is one where having an open-source core helps a ton.
In my role I'm often the one finding these and being a major influence in pushing for or against them, and one of the key things that pushes me away is having no exit path in case the company goes under, pivots or otherwise discontinues the product. If it's part part of our product or the delivery pipeline this is a critical factor, and sadly, I've said "no" to a lot of promising products for this reason alone.
I've been burned before by this, and having to drop everything the team is doing to re-build something outside our control is not good for anybody -- it looks bad on me if I chose the thing, it makes all the developers irritated they have to shift focus, it causes chaos to PMs and their schedules, and it infuriates sales and everyone up the chain from there.
Should be obvious, but: the more value the service provides, the more we're willing to pay, but also by its nature the more ingrained it is and thus more important there's an exit path.
In some cases, an alternate option is to put the code into escrow.
At one of the bootstrapped startups I was a principal at, a very large enterprise customer stipulated that we had to work with a much larger entity (with which they already had an MSA) and technically, the software was licensed and delivered through the entity (who ended up getting the support contract in exchange). The code was put into escrow with this larger entity in case our startup failed.
(For all intents and purposes, this entity was absolute trash and ultimately ended up actively sabotaging us in some later deals because they wanted a bigger piece of the pie).
OS core is one way; maybe more prevalent in very large orgs that require MSAs is licensing through another entity that already has an MSA and putting the code into escrow with the third party.
I worked at a startup where our software was in escrow, and we had a couple clients signed onto it. I've never been on the other end, though.
I can see a few problems with this. In the case of an MSA taking over, it doesn't necessarily satisfy the exit plan requirement, because as you say in another reply they could charge an arm and a leg. 10x'ing the price overnight isn't really much different from it shutting down.
The other issue: I am a developer and architect, I want to primarily design systems and write code and make stuff. Know what I definitely don't want to do? Sit in meetings and talk about escrow agreements with C-level people, lawyers and sales reps. If there are two startup products we could use, one is exact-fit amazing but needs an escrow arrangement, and the other is OS core but will need dev effort -- I'd 100% rather spend my time doing the dev work.
You can often search for press releases with big name services vendor or big name software vendor + your target customer and see if there are press releases. Many large companies work with specific partners for IT services and these providers are the ones with the MSAs that you can attach to.
Examples: Cognizant, Tata, Accenture, etc.
It won't be easy unless you know someone on those teams already. Sometimes if you find a customer that loves your product but cannot procure through a startup, you can ask them if they can refer you to one of their partners and see if you can work something out with them (most of the time, those partners will want an arm and a leg).
This is one where having an open-source core helps a ton.
In my role I'm often the one finding these and being a major influence in pushing for or against them, and one of the key things that pushes me away is having no exit path in case the company goes under, pivots or otherwise discontinues the product. If it's part part of our product or the delivery pipeline this is a critical factor, and sadly, I've said "no" to a lot of promising products for this reason alone.
I've been burned before by this, and having to drop everything the team is doing to re-build something outside our control is not good for anybody -- it looks bad on me if I chose the thing, it makes all the developers irritated they have to shift focus, it causes chaos to PMs and their schedules, and it infuriates sales and everyone up the chain from there.
Should be obvious, but: the more value the service provides, the more we're willing to pay, but also by its nature the more ingrained it is and thus more important there's an exit path.