Still True

Let’s add another item in the “things that were true before are still true” file.

This one is vendor lock in. This has been a problem forever, and it turns out it is still a problem. Whenever you decide to buy a critical service from a third party, you are accepting risk. If they break you, if they suddenly go out of business, if they get hacked, if they deny service to you, etc.. All these risks for their company are now risks for your company. This has always been true.

And it turns out, it’s still true:

It’s not just Claude:

MSFT has been doing this for CoPilot users also.

OpenAI, same.
I post these not to shame the vendors. They may have completely legitimate reasons for doing this. I have no information about this whatsoever. The point here is that when you build a business, you are by definition taking on risk. There is no way to avoid risk, you must manage that risk.

This means that you need to think about what would happen if the vendors you choose make a mistake or go bankrupt or suddenly decide to turn you off. Some of them are riskier than others, so your plans will vary.

One of the things you can do to protect yourself is to ensure you completely own your product. This is why I’m not a big fan of hosted no-code solutions. While it is very easy to build a storefront on Shopify, your entire business now depends on one company. If Shopify gets hacked or just randomly goes out of business, you are now out of business also.

However, if you build your business off of source code that you own and it is sitting on top of Open Source that you have the legal right to use, you are relatively protected. Yes, bad things can still happen, but they are less likely and easier to recover from.

So, in the case of Fictivize for example, I have chosen to host the site on AWS. There is no backup hosting site on another provider. If AWS suddenly goes out of business, my site goes down. However, AWS is the largest cloud company on earth, so I am relatively protected just by their size. I also own all the source code. This means that if in theory I needed to move off AWS, I could do so. It wouldn’t be easy, but I could do it. I actually seriously considered moving at one point during the site’s development and built an entire migration plan. I didn’t need to execute that plan, but I still have it. All of these things are much easier if your site is architected correctly and you own your source code.

These are always trade off decisions. Going back to Fictivize, I intentionally chose to consume several AWS PaaS services. Every time I did this, I took on more risk from AWS. Moving from AWS will be harder for me because I made that choice. It was a balancing test between getting the product out the door and the risk of getting locked in to a single vendor. Because of my personal history with AWS, I decided that the risk of lock-in was less than the risks of not shipping anything at all or the fact that I would need to manage all those components myself if I chose to build instead of buy.

Did I make the right decision? I think so, but time will tell. At the moment, the decision looks pretty good because I got the entire site up and running in just a couple of months. I’ve also had zero downtime in production so far. That streak won’t last, but so far, so good.