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.

 

 

Problems With Modern CS Education

I have noticed this weird pattern that when something is not in my academic syllabus and is interesting to me, it becomes an active pursuit, but for some reason when the same topic is up for the test, I procrastinate too much. Maybe it's just me, but it's an interesting recent finding.

I pondered about it for a long time, and as with everything in my life, I will blame this to something completely external—not taking accountability for a single thing wrong with my life.

 

 

 

Modern computer science education is bad. Not only is it outdated, but even the stuff they teach does not cover first principle thinking. And I am not talking about a certain type of institution; most of the problems discussed in this article apply to almost all of the institutions and even bootcamps. This article consists of rants and maybe possible solutions that can be applied to practice, but all of these are just my views. I will try to add references to all external sources I can find so that you can delve further into the topic of education and learning.

But first, let's focus on addressing the issue, as no problem is worth researching if we don't acknowledge the existence of one. I have spent my recent few months hiring people for tech roles, and without any surprise, they are not industry-ready even after we decided that we are ready to train inexperienced candidates. This is nothing new. At the current market conditions, even the people who deserve to get a job are facing resume rejections. It is way harder to get into the tech industry now than it was, say, a decade ago. This can be blamed on market conditions, an overflow of tech candidates, AI, and whatnot. But we are not here to rant on the system because, whether we want to or not, we are a part of it. We are here to know how to become the best. But we can't easily because modern education is failing us.

The first problem is their degree itself. Most of them report about how their CS major includes a whole tonne of non-tech stuff and just diagrams and equations instead of teaching them how to build stuff. While the syllabus does look good on paper, it depends on how institutions follow and teach them, which is still up to them. And unsurprisingly, most of them fail to do so.

Recently there is a rise of institutions which enroll the growing amount of interested students into their degree programs, and get accredited weird government benchmarks and sell dreams to vulnerable people. Most people I know have never learnt anything important from their college anyways.

Nevertheless, this is also the case with famous and overall reputable institutions with their useless assignments and subject placements. Like, for example the missing semester of MIT have stuff like version control and Bash? I wonder why they didn't teach them in the curriculum itself. I get it. Computer science is a theoretical subject, and software engineering is a whole different field. But still that does not explain why first-principle thinking is not applied to most approaches. Maybe it's just me who believes that going right into the project and dirtying your hands is a good idea? I am not the first one. Read the page; understand why those things are not incorporated in most schools (except some, which is amazing, btw).

From the transistor has a very novel approach to CS, and I like it. First-principle thinking is not only about understanding the inner workings of things, but it's also about why the thing exists there in the first place. You may know what an assembler is, but you will be shocked how many people don't know where it fits in or why it's even important, for example. This is a shitstorm.

Introduction

 

This was originally posted in Q1 of 2022

Hello All

Welcome to the first post on my blog. I used some other platforms to blog before, but I think having a custom website for my writing and archives is a better choice. This post will be a little bit about me and what I will post on this website.

About Me

I started programming seriously when I was in 8th grade (around the age of 13). I'd written some code before, but only to experiment with computer science; I was just doing it because I enjoyed tinkering with my computer in addition to playing games.

I am working on hackarmour, as well as researching and developing compilers and blockchain projects. I have a couple of them on my GitHub. This blog won't have much educational content because I believe there are enough resources out there to learn anything (in computer science) for free. But that doesn't stop me from posting some free advice and rants.

Web Dev

I made some websites. It helped me understand browsers and how the internet and servers work. Most of my work, even today, deals with the web in some way or the other. I use the full stack JavaScript and sometimes Golang. So I may post some posts featuring some of my work related to microservices, cool server architectures, project demonstrations, and my rants about the node package manager and useless things in web development. Do not expect me to post tips or tutorials on this blog. I may explain some concepts at times and will link most of the resources you may need to research more on a particular topic. I have already created a resource list which has some really good web development resources.

Hacking

I started learning about some security from a developer point of view around the end of 2019. I started out with web security because that’s what made sense back then. Then I got familiar with cryptography, forensics, more Linux, and CTFs. I also stumbled upon a LiveOverFlow video about how CPUs work, and all those experiences made me more aware of how computers work. I still don't know how to hack stuff. Web hacking feels very boring, and I hate scanning or brute forcing. But I’m trying out some reverse engineering and exploitation these days with my malware research, so I may post some cool hacking content as well.

LiveOverflow: Youtube

Systems Programming

This is the main topic of this blog. I mainly made this blog to document my progress in the 3 yearlong system programming roadmap I created for anyone to follow to get familiar with the concepts and make cool projects on topics like compiler engineering, browsers, malware, and exploitation. And even some references to learn about OSDev.

I haven’t had much experience in systems programming apart from making a programming language, (which I will be documenting actively on this blog). I also have to do more research on malware, OS, and also make a project on simulation. I will also be writing about some cool concepts which I liked in the process of learning those topics and will also give resources and techniques I used to learn them.

Conclusion

I will try to keep this blog active by posting twice a month but may fail to do so because of some unforeseen circumstances. Thanks for reading this far. Have a good day/night and happy hacking.