How to build an MVP
Earlier this year, Hugo explained what a Minimum Viable Product is and how it can help your business see results and build relationships with customers quickly and effectively. But once you’ve identified your audience and got your killer idea, where do you start? Through our experiences building brilliant launchpad apps for businesses, we’ve come up with a checklist to get started ASAP.
Pick your platform
Web? Mobile friendly? Native? It’s vital to understand where your users are going to be most likely to use what you’re building. MVPs are all about keeping things as lean as possible. If your app is going to be used primarily on-the-go then don’t spend time on a flashy desktop experience. It’s useful to think about connectivity at this stage too. If you need to provide some offline functionality then that should steer you towards a more native experience, for example.
Where to base data
We tailor every project to the data we need to be handling. After figuring out the core building blocks of our data structure, we look at how they need to relate to one another and how we’re likely to need to query them. Are there lots of complex relationships? A traditional relational database system like MySQL would probably be best. Does the data need to more flexible or document-based? We’d probably lean towards MongoDB as a NoSQL solution.
Tooling around
MVPs are typically built with a tight deadline and, as such, it’s really useful to build up a suite of tools that can help you save time without cutting corners. We love AWS Cognito, for example, as it takes away all the hassle of implementing user accounts and authentication without compromising on functionality or security.
However, balance is crucial. If it’s going to take you time to rip out and replace a stopgap measure with a more permanent solution, it might not actually be worth it. This means you either need to pick systems you can rely on as demands increase or build with ease of replacement in mind so that, when the time comes, you’re not forced to reinvent the wheel to keep things stable.
Scalability
Your MVP is likely to start off small with a few test users but what happens when it’s a success and the floodgates open? Using systems that can scale smartly can save you a lot of hassle and cost both when things are quiet and when they step up. If you’ve embraced Serverless design then this is of real importance - your app may be cheap to run now but what if it’s ten times busier? One hundred times? A thousand? You also want to make sure that your code is efficient enough to not create a bottleneck and slow users down as their demands grow in size and complexity.
Future-proofing
Unless you’re Pepper the greyhound, it’s impossible to predict what’s going to happen in the next 2 months in tech, let alone the next 2 years. Hopefully, your MVP will grow into a fully-fledged application. What happens, though, if a new feature needs to integrate with your existing work? Or a key third-party service gets abandoned? Be careful not to force yourself into a corner when architecting your MVP. Remember - it’s the starting point and should be able to change (sometimes radically) as you progress towards the final product.
You can discover more of our MVP & Prototypes Insights articles here.
If you’d like to discuss your MVP idea or any other projects, just drop us a line.
