Case Study – Building an MVP
Do you need to build an MVP? Building an MVP is one of the challenges new entrepreneurs face. To help you understand how the actual process works, we thought using a sample case study could be useful.
Start with the Idea
Let’s say that your idea is an app that would connect users to restaurant reviews. You probably have ideas for a bunch of features. For example, you might think about the following features:
- Users can create profiles and leave reviews for restaurants
- Restaurants can create profiles which users can leave these reviews on
- Users or restaurants can upload photos
- Users can search for restaurants based on geography or other filters, like what kind of food they serve
- The platform can display advertisements or special offers from restaurants to users
If you have questions about how to come up with a new startup idea, check out this helpful article.
Identify the Scope
You’re probably familiar with some websites that offer these features – which is why I’m using it as an example. Let’s think about this project from the point of view of building an MVP. While this may sound straightforward, there are actually a lot of specific elements that need to be developed. To make this, you’d need to build at least the following features:
• The infrastructure to allow for users to create new profiles
• The form to create a new profile, set password, send reminder for lost passwords, confirm users
• The infrastructure to allow for restaurants to create profiles, set passwords, etc.
• An interactive map that shows restaurants
• A filter to sort the restaurants on the map by a number of criteria (pricing, location, food type, etc.)
• A platform where users can post reviews
• The interface for restaurants to post responses
• Security measures to prevent or deal with spam posters and bots
• An infrastructure to let advertisers display ads to users
• The capability for users to place online orders. This requires installing a payment mechanism, and having an interface to process and track orders. This will also require a customer support feature in the event of lost or mistaken order.
• A way for restaurants to show special deals to users. This includes thinking through the logic of what kind of users they show to (e.g. x zip code). It also requires a user interface where the restaurant can upload and change deals, set the duration, etc.
The exercise of listing out all functions in a software is called defining the scope. When scoping, the developers will list down all features and goals of the software. They will then determine how long each will take, and in what order they should be done. A scope results in an estimate of time and cost for the project. For more information check out this helpful article.
Narrow Down the Critical Functionalities
As you can see, a seemingly simple idea has many different features, all of which need to be built separately. When added together this is actually a quite complex project. When looking at this from the point of view of building an MVP, the idea is to start small. Let’s consider how we could start our project with just the features we really think are vital. So, in this case let’s start cutting down to the bare bones.
Let’s say that perhaps we can live without making users to create a new profile altogether. How can we make this easier for them, and for us to build? One idea is using a social media login feature with a popular social networking site. This way users can login and not need to remember a new password or create a new account.
We may also decide that we should first ask users what criteria they are interested in before building filters. We may decide to start without an interactive map, and instead just list restaurants by name and zip code. This will be faster to build, and will give people the ability to quickly find restaurants in their area.
We may also decide that the most important thing for now is to have people review restaurants. We aren’t sure it’s important to have restaurants also post responses. So let’s save that feature for later once we confirm that people want it.
Lastly, we may decide to wait until we have advertisers interested before building the functionality to show ads. We also don’t have the staff needed to make deliveries – so we decide to make that something to think about for the future.
The result is that we have modified and simplified the project scope. We can now update our estimate in terms of time, effort, and cost. YourCTO always offers a free consultation, during which we will scope your project. Contact us if you’re interested in scoping your idea!
Getting to a Minimal Viable Product
The result is that we will make a simple, nice looking platform, with basic features. This lets users find and review restaurants in their area. We can build this quickly and for a limited cost, and get it to initial users to test and give feedback. We will learn much more from actual users and can continue to build from there. For example, the users may tell us that they want a searchable map interface. If so, great – let’s now invest in making that since we know people want it. If they don’t actually seem to want this, let’s not build it.
Whether or not you decide to work with YourCTO we hope that his example helps you wrap your head around how to start thinking about how to approach building an MVP. In our view, less is more – and we’ll never try to sell you on the idea that you need to build every little feature because it would raise our price.