So the question is what are your "Plan B" options. Let's assume for a sake of argument you've weighed the options (build your own, buy from an established competitor, partner with this startup) and you've decided that partnering is the best option. One way you could protect yourself in the event this company either shuts down or pivots and no longer supports what you need, you could negotiate to have the code put in an escrow account that has triggers to release the code to you. You of course will be restricted to the usage (e.g. you couldn't take it and compete). I've used escrow agreements in past deals and can discuss the details if your interested. Caveat, I'm not an attorney so can only provide business advice. Good Luck!

As someone who has both practiced lean startup methodologies, as well as someone who values their own time.

Go with the small startup's API until you have other resources other than yourself who can develop better than you can. It's just not worth getting tied up reinventing the wheel when it si your job to defer, outsource (elance, odesk, freelancer.com, guru.com, gun.io,) or lisence their code. Your responsibility is to move the company forward in big steps toward its core mission. Not tackling something because you think you could do it.

If you would like to discuss this further, give me a call. On the house.

When you wake up in the morning, say to yourself "Get to that MVP" 3x. Saying that would make the answer to this question a no brainer!

Good luck!

You don't even necessarily need the code should they pivot and do something else. You just need contracts in place for support. You need them to support you for a certain length of time and even have a stipulation that they support you for yet another length of time after they pivot or no longer have whatever version of the API it is.

That way, you'll have time to build your own. OR at that time you can negotiate buying it from them or upgrade to the latest version of their API.

No one is going to want to just give you the code should they pivot and make a new version. As a developer, I wouldn't. That's potentially trade secrets, etc. However, I would certainly sell it to you (maybe ensuring you don't resell it) should I move on and not want to support you with servers, etc.

But really, what's it take to keep a server around, with an older API version, for one paying customer? It's not as if they are losing on the deal (hopefully).

We're in the business of software here and the good thing is that there's absolutely no reason they would ever lose some version of an API. They could always go back in their revision control systems and resurrect it. So you aren't going to lose it. Not if you have an agreement. Though that agreement doesn't need to be harsh. It should be quite easy to negotiate.

I've been involved with the creation of several apps for startups that were based on third party APIs as a central piece of the software architecture. From my experience, there have been pros & cons to this approach, but I would generally recommend using the API if you can.

Things to watch out for:

Is the API a new API? If so, proceed with caution. We've worked with several third party APIs where we were the first or among the first developers to use the API. In each of these cases, there was a significant amount of back and forth with the API development team that extended the development time required to complete our app. This was sometimes due to API features that were in the documentation but not yet implemented. Other times, it was due to features that were available in the API, but not in the documentation. And yet other times, some of the documented features were present, but not functioning properly and we had to wait for bug fixes, clarification, etc. If the API is mature and is in use by a large number of users, most of these issues will be ironed out. I don't think you want to be the ones who end up doing the ironing though.

Do you have options to create an alternative source for the data? One app we worked on had maybe ten 3rd party APIs baked in. Over time, we replaced a number of these APIs with our own home grown solutions and some of them we swapped out for other 3rd party APIs that were cheaper, better, or faster. You may not need to have all of this completely figured out, but you should have a rough idea for plans B and C that you can pull trigger on should the need arise.