Stop Building for a Cloud Migration That Never Comes

Someone probably told you to keep your product “cloud-agnostic” so you’re never trapped with Amazon or Microsoft. That advice sounds safe, and for most founders it burns runway.

In practice it means your team wraps everything in extra layers so the code never depends on one provider. The work AWS or Azure already does for you gets rebuilt or hidden behind a generic interface, just in case you switch someday. That’s insurance you pay for up front, in slower development and more code to maintain. In twenty years I’ve watched a lot of teams plan for a cloud migration that never came.

I go the other way. When I built a monetized SaaS solo in six months, I committed fully to AWS: Rust on Lambda, DynamoDB, SQS and SNS, CloudFront. No portability layer. On a current project I’m all-in on Azure the same way, Container Apps and Bicep. Committing to one provider is what let both move fast.

Lock-in is a real cost. It’s just rarely the biggest one in front of you. Rewriting your product a year late because you were too busy staying portable to ship is worse. Pick a provider, use it deliberately, and revisit only if the business forces the question.

If your dev team wants to build an abstraction layer “so we can move later,” ask them how likely that move really is, and what shipping slower today costs you against a move that probably never happens.

When has keeping your options open actually cost you more than just committing?