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 

 

 

 

 

 

 

 

 

 

 

ScratchBox Project Announcement

Introduction

It's been a while since I created some open-source software. But I am going to again create proprietary software because I have taken interest in product development and, like, launching stuff to see how people react to using it. I have been reading the Lean Startup by Eric Ries and Zero to One by Peter Thiel. And also been working with some cool people to create a B2B SaaS. 

These experiences have contributed to the thinking that I can earn actual money from my misery, which seems cool. That is when users find my product cool enough to pay for it. For this new product development, I have chosen to play by the books except for the initial stage of MVP development. I did not ask people about my idea not because I already know it was the best (I don't), but because I did not want any scope creep while building an MVP.

 

 

Startups

Creating a startup out of this will be my last goal, we are here to learn. I should do or at least pretend to do serious things at an early stage of my career which prepare me for the harsh world out there. With that being said, I have learnt the hard way about scope creep while building our previous B2B SaaS. Requirements kept on changing, technical debt kept on increasing, and at the end the most valuable resource was almost empty: time. We took around a year to deliver software which could have taken only 3 months to make. We went by the books of this one. This felt more like a client project rather than a startup. Not cool.

So, this time by learning from the mistakes, I am finally creating another B2B product. Will this time it would be better? I don't know. The problem we are trying to solve is kind of related to my previous article. We are trying to create an Ed Tech product. We have the MVP down, it has a lot of bugs and a lot of feature improvements. But people kind of like it, and our vision.

 

The Product

The product currently a coding playground, where educators can assign problems to their students. That's it. It is a HackerRank clone. But it's better in terms of our execution engine. We perform more in-depth tests, semantic analysis, custom invocations, custom testcases which are capable of testing things more than DSA problems.

 

 Actual people using our platform

  

But the real sauce isn't the features, as we can pivot anytime based on further feedback. We are testing this product in our college right now, and if they like it and find it useful, we will think about scaling it up, raise funding and do what startup people do.

I will be writing another blog on product development and what steps I am taking while we develop this. And I named it ScratchBox. Scratch: creating something from scratch; Box: Represents the coding sandbox involved at the heart of our product.