55. How do you build an MVP on AWS?
Sometimes people talk about an MVP and then say "yeah but we deploy manually" or "we don't have tests yet". Is that really an MVP or is it something else? And what it takes to build a successful MVP when using AWS? In this episode, we discuss the differences between a prototype, a proof of concept, and an MVP. Then we debate about what's the minimum amount of work you need to put in place to have an MVP on AWS. We debate on whether our weshare.click is an MVP or just a prototype and why. Finally, we provide a list of previous episodes that can help to acquire the foundational AWS knowledge that is needed to be able to build an MVP successfully.
Some of the resources we mentioned:
- The book "The lean startup" by Eric Ries
- The weshare.click repository
- The YouTube playlist of all our weshare.click live streams
- The YouTube playlist of AWS foundational knowledge videos
If you're building a new workload on AWS or migrating an old one, it's always a good idea to start with a Minimal Viable Product or an MVP. But what is an MVP and how does it differ from a proof of concept or prototype? What is the minimum you should do? And how do you ensure that everyone has clear expectations around what the outcome should be? My name is Eoin. I'm here with Luciano and this is AWS Bites.
Okay. I guess we can start this podcast by asking, why are we asking this question in the first place? Why do we feel that there is a disconnect with how do we perceive what is an MVP and what people actually say when they talk about MVPs? Yeah.
I see this quite a lot and maybe it's a bit of a bugbear of mine, but we see teams embarking on a new project and the term MVP gets used a lot. So often this term means a lot of different things to different people. And the lines are kind of blurred between what's an MVP and what's a proof of concept and what's a prototype. I think it's a good idea to break these terms down and just figure out what the different differences are between them before we talk about how to build an MVP and make sure you set it up for success. So a prototype is not a product. It's like a rough idea used to demonstrate some capability and it's something really useful, but it's ultimately a communication tool that you can use to show others what a product might be like, or just to get buy-in or even to get funding. So it's like a decision-making tool. Then on the other hand, you have a proof of concept or a POC, and that's typically designed to validate some assumptions, to test a hypothesis, or to just evaluate whether a technology is going to work for what you want to do. So for a POC, you should have a clear question you're trying to answer, or like a risk you're trying to remove, and you should know at the end of it whether you can proceed or not. So neither of those two things, prototype or POC, neither of them are really a product and they don't even have to become the nucleus of a product or grow into a product. They're just part of the assessment and discovery phase of a project that you might do at the start. So you could even throw away the code when you're finished, right? That's kind of what you should expect with those things. So they might be minimal, but they're not a product and they're not viable either.
Yeah, I like when you say you should also be able to throw away the code, because I feel that a lot of companies and people in general gets very attached to their code. It's like the value is the code itself. While that might be true in most cases, the reality is that the value is in the discovery that you made, that the value is in the proof that you have created, that your idea might be successful or the technology might work for use case. So you can actually rewrite the code and probably the second time you're going to rewrite it, it's going to be even better. So I definitely like what you said there with throw away the code if it needs to be, that's not the value, that's not the product, the value somewhere else. But I guess the next question is given that we define what a prototype is, what a proof of concept is, what is an MVP then if it's not these two things?
Okay, so literally the first thing, it's minimal. So that's like going back to like Eric Ries and the Lean Startup and then the Lean Enterprise, all these books are really good at telling you how to focus on what is really minimal and you want to deliver the smallest amount of functionality you can get away with. Just kickstart that product feedback life cycle. So that's the minimal part. But then probably the difficult one is the viable bit. So when we're talking about viable, we're saying can your team sustainably evolve and support the ongoing development and operations starting with this MVP.
So a prototype just kind of held together with sticky tape is probably not viable. So it's important to think about what viable is. And then when we say product, that means that you're aiming this at real users with real needs and they're trying to get something important done with it. It should be ready to sell. And it should support meaningful scenarios that users are using. So sometimes you hear things, people say, oh, we're building an MVP and we've got our MVP ready to go.
But you might see or hear them say sometimes we're still deploying manually or we're already planning a complete rewrite of this. This is just the early version and it's running on a single EC2 instance in a public subnet. So maybe what you have in those cases is more of a prototype than an MVP, but it's not just about the technology. And it doesn't mean that when you're building an MVP that you have to boil the ocean and all of a sudden you have to achieve perfection. It's just about like you can still have an MVP that doesn't have any code at all. It's a completely manual approach based on Excel sheets and human interaction and a documented process that can tick all the boxes for an MVP as long as it's sustainable. So it's not about whether you have tech or not. It's important thing is that you've got really good performance that you've got rigor that can actually support the users no matter what happens. And it's something you can build on and evolve over time.
Yeah, I really like this definition and I suppose it makes sense to... Yeah, I agree that basically the viable part is the one that most often is the one that gets the least amount of attention. And it's something we should be focusing a little bit more at least for when it comes to the technical side of things. We always disregard it and say, oh, we're going to do that later. It doesn't matter right now. We can do this manually or we don't need testing right now. And then eventually if the business goes well, it's very hard to keep up and it's not sustainable anymore because you miss all these foundational blocks. So I suppose what's your perspective on this? What do you think you should be putting in place as the bare minimum? I suppose mostly from a technical perspective to consider that the product is viable and therefore it's sustainable.
Okay. Well, if we take the M and the P first, let's say you... Let's assume that you've got the right minimal set of features from the beginning and then you've got at the product side a system to gather feedback and iterate on the product. Then in the middle, I'd say if you're building a technical solution on AWS, you should try and put in the minimal fundamentals to make it viable. And those would be things that you and I have talked about on the show a lot over the past 50 or so episodes. So we're talking about infrastructure as code, unit tests, end-to-end tests, automated deployment, some level of observability with like centralized logs, metrics, alerting, traces, some security fundamentals, of course, because otherwise you've got a business risk that might really compromise your viability. Having the right skills within your team is also something that makes your thing viable. So maybe, especially in a startup scenario or even in a migration scenario while you're adopting the cloud, there might be a huge risk to supporting these workloads if you just kind of completely wing it and don't have the skills in place or at least a plan to address skills gaps. So even think about stuff like that as part of your MVP early on. And then of course, like documentation for onboarding and troubleshooting from the start, right? So you can bring people in, new people as the team grows, et cetera, and you don't have to kind of, I suppose, train everybody up manually or rely on them to kind of somehow assimilate all of the ideas that are in the code base. It's a good idea to have some documented principles and training in place for people too.
Yeah, I like what you said there. And I think that was one of our previous episodes where we mentioned that we were building a particular solution and we opted for just plain EC2 instances where we could have gone with serverless and Docker, but we made that conscious choice because we knew that the team that was working on this solution and eventually would need to support this solution didn't have a lot of expertise with either serverless or Docker. So we will still want to achieve all the benefits of the cloud while allowing the team to be able to support the solution long-term. So there was kind of an interesting trade off where from an architectural perspective, maybe we would have wanted to use something else, something more innovative, more kind of less management, but at the other side, we didn't want to overload the team with new knowledge that they didn't have the time to create on the team and make it sustainable that way. But at the same time, it's interesting because you might wonder, isn't this too much work for an MVP, right?
My opinion is that yes and no, it might look like a lot of work, but at the same time, if you do it in advance at the very beginning of your project, it's work that you can actually do in an environment that helps you to do it. And it doesn't go against you because you are not focused on serving the customer, but you're actually focused on building this foundation that later will allow you to serve the customer. So definitely cheaper to do it sooner rather than later in a project. And again, there are different degrees. You don't have to do it perfectly. You don't have to do to have perfect infrastructure as called 100% coverage unit test or observability with hundreds of metrics and alarms. You can build all these things and improve them over time. I think what's important is to have a basic, to have an understanding and to have something that gives you enough indication of what's happening right now. And then over time, as you build new features, you can tweak and improve also these aspects. So yeah, I guess that's also important to understand that when we talk about all these items, they don't have to be something like fully fledged 100%. You can build the bare minimum there, make sure that it works and it's going to support you and over time make it better as you're going to be making better the entire product itself. Agreed. Yeah. Keep it, go for the simplest possible implementation of each of those things.
And then you've got a good foundation. You can always iterate on it later, but you've got something.
So what do you think in terms of, you mentioned one of the cases before you say that sometimes there are businesses that they don't even have tech at all. They just run, maybe they have Excel. That's the best that they do from a technical perspective, but everything else is pretty much manual and it's still, it's a pretty successful and viable business. What do you think is the risk there when they start to do digital transformation and actually implement a lot more tech in their workflow? How do they have to think about an MVP and starting to bootstrap all that process?
So I guess the main point there is that you can have a really well oiled machine that isn't a machine that's completely human based and people who know exactly what they're doing, they know what the process is, they know where all the data is, they know how to use their Excel sheets and they're really good at interfacing with the customer. And then when you take that and you're trying to do a digital transformation on it, you've actually got pretty serious obligation because you're trying to replicate the success of what that human team has been able to do, but you've maybe you're trying to do it in a more scalable, automated way. So when you think about your minimal viable product, you've got a pretty high bar already to meet because you have to make it really as viable as what came before. And so you're trying to implement scalability without sacrificing the excellent capabilities of that team of people, which is very difficult thing to do. So I just think the main thing to say there is that okay, yeah, you should tick all those boxes that we mentioned already in terms of having infrastructures code and unit tests, but you should be aware that you actually have a risk by building a technical MVP if you don't have the same rigor and foundations in place that your manual process has. Yeah, I totally agree with that.
I actually now want to make a little bit of an experiment because if you have been following this podcast, you probably have noticed that we have done a series of live streams where we built, let's call it a product, I don't want to say an MVP or not. The experiment is actually to try to assess if that was an MVP or not. And the product is something we call WeShare, which is like a, I don't know, a clone of WeTransfer or Dropbox Transfer. So upload a file, get a URL, somebody else can download the file with that URL.
So what we did is basically we put in place some of the things that we say that are needed for an MVP, but maybe not all of them. So I'm going to try to do a mental exercise to try to list all of them and say yes or no, whether we did a good job or not. So we did do infrastructure as code. We used the serverless framework and everything was pretty much infrastructure as code, multiple stacks. So I feel pretty confident saying that we did a good job there. Unit test and end-to-end test, probably more than a no, than a yes. We have a few unit tests, mostly as an example of how you will test specific APIs, but I wouldn't be comfortable saying that this unit test, that the ones we have right now will serve customers well, assuming that there will be customers using this application.
So probably more of a no than a yes. We should be doing more work there. Automated deployment, absolutely not. We were deploying manually. You might've seen the pain of SLS deploy, waiting three minutes and then trying again. And yeah, not committed code was deployed and all this kind of stuff. So definitely a big no there. Observability, maybe a 50-50. We did show some stuff. We did show how to do custom metrics. We did have structured logs in place, but we didn't do anything useful in terms of actually operating on this data. We didn't have alerts. We didn't have dashboards. We did try to set up tracing, but we kind of failed at the first attempt. And then we said, okay, we're going to revisit this later and never got back to it. So again, observability is probably 20%, but definitely not a yes. It's more of a no than a yes. Security fundamentals, probably we did a good job. I guess we covered the basics. We tried to write very restrictive policies. So we have an authentication mechanism. We did try to do at least the minimum kind of work there. So I'm confident on that one. Skills, I believe that if we consider ourselves the operators of this product, we did rely on skills that I think we have. So probably yes.
Documentation was probably a little bit more of a no than a yes, but recently we put a little bit of effort in actually documenting the entire setup process and how does it work, what it does, what kind of infrastructure it creates. And people should be able to actually take all we have and deploy in their own accounts. So probably more of a yes, but used to be a no a few days ago. Thank you for that.
So one interesting thing before we try to assess whether this is an MVP or not is that I think our goals are not entirely clear with this particular product. On one side, it was meant to be more of an educational product. So the product itself is not the WISCHER thing, like the actual product that allows you upload and download files, but more the whole experience, the showing people how to use serverless, how to use AWS and how do you build something from scratch. Like what is the whole experience there? So that's maybe one aspect of the product. Then if you want to consider the actual tech product as uploading and downloading files, that's an entire other story and it would require to have users, which we don't have right now. So I'm not really sure how we should consider that one. Do we consider a potential future product? Do we want to consider product because we use it ourselves? That's probably to be assessed. What do you think? Do you consider this a successful MVP or not? Or maybe it's more of a product.
No, not as a product. As an educational product, I think, yes, it is viable as an education thing and as a how to build stuff on AWS, for sure. I think there's plenty of lessons there for people. I'm satisfied with that part. But as a product within that, no, because you have to be serious ultimately about supporting users if you're going to do a product and that's not what this is. But maybe somebody out there will take it as inspiration and build our super successful startup ahead of it and become a unicorn and we can say we were there at the start. Remember about us at that point.
Yes. Send us a gift or something. Exactly. Buy us a coffee. So I think maybe let's just wrap it up with a couple of thoughts.
So we said that an MVP needs clearly defined minimal scope. You have to have a product part, real users with a real need and you need on the tech part, rigorous foundation with deployments, operations, security, et cetera. So you might agree or disagree with the checklist of what it takes to have a real MVP. The most important thing really is that when it comes to what it takes to have a real MVP, that should be defined within with you and your team so that everybody agrees what that is and that you're not talking about different things and having completely different expectations about the level of quality and the level of sustainability in that product. Because often problems arise when people assume that, OK, it's an MVP, we can take shortcuts on loads of the fundamentals here. And other people are thinking, OK, no, this is a really complete solid product, it's just a minimal set of features. So agree those expectations early on and you can avoid a lot of confusion and conflict later on. Do you think we can refer people back Luciano to some of the previous episodes? Maybe when it comes to the actual how-to of building an MVP, there's a couple of links in there. What do you think? Absolutely.
I don't know if they are well-structured, but definitely if you listen to them, you will extract some information that is definitely relevant for the topic today. It's definitely going to give you elements on how to build your own MVP and what kind of technical aspects you need to focus on and how to do those things in the context of AWS. So we have episode nine, which is how do you get started with AWS, which tries to cover all sorts of different things that maybe not obvious if you are approaching AWS as a newcomer. Like what are the main things you should do straight away? What are the main topics you should get yourself comfortable with?
Actually, I think AWS has a pretty high barrier to entry. It's not just get a server deployed. There is just a lot more context that you need to get before you are in a position that you can actually put something into production. So I would recommend that episode to cover all of that. Then we also have episode 15, which is is serverless good for startups? This is more of an opinion take and it's something that if you have been watching our live streams, you can kind of correlate more of an opinion. Would you use the same approach for your startup? Yes or no?
Why? In which circumstances? Probably you're going to find an answer there. We have a few episodes on observability. We have 33, which talks about CloudWatch metrics, 34, CloudWatch alarms, and 35, which is more about how do you query logs with CloudWatch. We have another one about infrastructure as code, which is episode 31, where we try to compare CloudFormation or Terraform. This is probably one of our most successful episodes, probably because it's a little bit of a flame war where I think I vouch a little bit more for Terraform and Eoin vouches a little bit more for CloudFormation. Again, you might have opinions. The important part is to do something about it. Maybe you can use CDK. Maybe you can use Pulumi. Just do infrastructure as code in whatever way. It's more convenient to you, but just do it. Then finally we have episode 37, which is how do you migrate a monolith to AWS without the drama. If you want to watch our live series of live coding sessions, we have a playlist on YouTube. We are also going to have the link to that playlist in the show notes.
Luciano will try and make all that very accessible to people on YouTube and in the show notes as well. Thanks very much for listening, everybody, and catching up on our latest AWS Bites. We'll see you in the next episode.
Use the arrow keys to move between transcript segments, Home or End to jump to the first or last segment, and Enter to seek in the video.
Help us to make this transcription better! If you find an error, please submit a PR with your corrections.