ScratchBox: Building the MVP

Introduction

This is the follow-up on the previous post, related to how we built our MVP. The coolest part about the MVP was that it was done within a week, which is one of the craziest things I pulled off. I will share more learning and stuff to document and archive things I learnt from this product.

The experience of building something in a week and having real people use it instantly and provide feedback is very memorable for me, so hence I am documenting and archiving that feeling.

 

   

 

Minimum Viable Product

MVP is a product which has just the right amount of features to convince the customer to use your product. A product with a shit ton can also be an MVP if you argue enough that all these features are important altogether to convince the customer. Which might not be the case. MVPs are also mostly time-bound. That time can be anything proportional to how you see your product in terms of complexity.

I have learnt 2 things about MVPs. First: if I execute early enough and act on it fast and release whatever I think is cool, I at least ship things. Second: you need at least one good main feature to work completely on your MVP before you call it an MVP, before that it's just a whacky proof of concept.

Tech

I am mostly a tech person. Tech does not matter when you show off your MVP. I chose to build a hacky proof of concept execution environment for the code to run, used MongoDB (turned out to be a good choice) and used Golang. I am proficient in it, they are fast and scalable solutions and I did not give it a second choice. Furthermore, I did think of using Scala, though, but it was my monkey brain acting.

1. Do not think about tech when you make your MVP. Just use whatever you know. 
2. Do not think of optimizing and scaling. Your first 3 customers are not going to heat your servers.
3. Do not include any fancy analytics. I used ssh + docker compose logs to monitor is my code crashed or not. 

If your tech is good enough to test your idea, then it's fine.

Collect Data

Collect everything. Each feedback, opinions, all logs, all crashes, edge cases, potential improvements suggested by someone who has nothing to do with the app, the room temperature, the weather condition. Everything. All data is valuable for you to know one thing: Should you continue with your idea, or should you pivot?

Pivoting does not mean you were wrong. I mean in a sense it does, but now you understand what people want. You are out of your imaginary state of mind and are working to solve real problems people might have. This is progress.

Test each and every hypothesis you might have with your app. Does this button belong here? Will anyone ever notice this feature? Take a note of these things when you develop your app. Test it when you make people use your app.

Conclusion

It was a very cool experience learning all these things and using it in real world in real scenarios. Most of my life, I have been involved in tech and now when I see people using my app and suggesting features, I think I can probably do all this for the rest of my life and not get bored. Solving problems will be a bonus.

Some resources I like:

Startup School: https://www.youtube.com/playlist?list=PL5q_lef6zVkaTY_cT1k7qFNF2TidHCe-1 

How to build an app by Tom Scott: https://www.youtube.com/playlist?list=PL96C35uN7xGJu6skU4TBYrIWxggkZBrF5