The concept of a Minimum Viable Product (MVP) is a fairly common concept in business. The whole idea is that you want to build fast, ship as soon as you have a working prototype, and then iterate quickly as you get customer feedback. It greatly reduces your initial ramp up cost, allows you to get to market quicker, and improves the final product since you get feedback earlier in the process. This type of methodology is used in every industry, both for physical products and for digital ones such as web apps and software development. The hard part tends to be defining what your MVP will be. You want your product or service to be fully functional, meaning that your users will be able to do anything that was advertised as being a core functionality of the item, but with none of the additional bells and whistles that you may add over time.
As expected, this concept also works within the cloud. Whether you're working on new software, a web site, or anything else that runs digitally, it's possible to ship an MVP from the cloud. In fact, many companies have switched to using the cloud especially to allow them to ship in a quicker and more agile fashion. When it comes to building an MVP however, it may be more difficult to figure out what your solution should contain at launch, and what you can leave for a later time.
Taking advantage of hosted features
The cloud has a large advantage for building a MVP because it allows much quicker deployments. You don't have to buy and install a physical server, you can launch an instance right from the web console. You don't have to build an entire database from scratch, worry about scaling or even manage the database yourself, you can use the hosted database solutions. There are even features like AWS Lightsail that allow you to write a very small amount of code, and the cloud provider will worry about deploying servers, handle scaling, DNS, APIs, and so on.
For building an MVP, using hosted solutions is a great way to increase speed to market, for a small additional cost versus building the entire solution yourself. In many cases that may make financial sense assuming that you can recoup that investment by being live earlier.
Security and reliability
Places where you shouldn't be lax on is security and reliability. Many people think that because you're in the cloud, security is solely on the cloud provider's shoulders. It's true to a certain extent. For example, if you use a service like Lightsail, you don't have to worry about applying security patches on the servers. However, you're still responsible for your own code. In fact, anytime you create any code, you need to make sure that security and reliability isn't an afterthought. Safeguarding your customer data, and making sure your app is reliable, is key to success, because if something happens early on, it may hurt your brand and your customers in a way that can't be patched down the line.
It's very easy to make exceptions when it comes to things that take longer: Why worry about unit tests now, let's go live and we'll add tests at a later time. Why worry about having a fully automated deployment CI/CD pipeline, we can just upload our code manually and worry about automation some other time. These types of thoughts are very easy to have, but it's very important not to fall prey to this. A proper design will allow you to decide what is an actual nice-to-have, and what might have an impact on security or reliability.
Having realistic timelines
It's easy to think that anything in the cloud can be done instantly, but as someone who's handled large cloud projects for almost a decade, I can assure you that timelines are always underestimated. While it's true that you could launch a compute instance within seconds, if you care about your business at all, the same care must be taken in the cloud as you already do with on-premise solutions. Skipping on important pre-launch stages always end up with longer and most costly changes down the line.
There are a lot of ways to speed things up, from using hosted solutions to employing an agile / sprint methodology. But never compromise on important things like the security of your data or using DevOps methodologies, even if they tend to slow things down, or you're only going to build technical debt that will impact you in the future.