(7 min read, January - 2021)
Hey folks, Harshal here.
I am writing this as of 18th April 2021. After months of (not so productive) work, I am happy that Reach is finally ready to be launched. I warn you to not get your expectations high, this is going to be a boring, unglamorous launch, but I am really happy regardless. ** In this write-up I want to share the philosophy and methodology that went into building Reach. If you wish to build your project and don't know where to start, I hope that you at least take away a directional structure that goes behind taking something from zero to one. I wish to keep this as relatable and educational as possible. This post is also to push me to write better and getting more clarity on my thoughts as it will push me to address something even remotely stupid before publishing.
Reach started from a simple question Elroi and I have pondered over years - How do we optimize learning? In May last year, Elroi came up to me with an idea - Is it possible to use public spaces to support bookshelves that could become a stack for people to leave their used books so that the ones who needed them could visit the place and pick them up according to their need. The idea was to create a self-sustaining local community where every person could benefit X times what they contributed. There were a couple of problems with the existing structure -
Creating such a public bookshelf meant assuming that one needs to start with a low trust approach - the shelf needs a keeper and is initially accessible to a large enough group but not all. Elroi said he wanted to start with his local church community that was close-knit and had thousands of members. He was pretty confident that the church would give us a little space to start with and that we'd have enough rotating volunteers to watch out throughout the week. The problems with projects having implications in physical spaces come with scaling issues though. Over time, the idea switched to an online version. Book sharing is not the only thing we want to solve with Reach, but we thought of going ahead with it as the first identified transaction. The other problems we are trying to tackle are not straightforward to address from both Design and Implementation perspectives but we hope we'll eventually get there. Right now, I think there's a ton that we can do in this transaction itself so this will be our singular focus in this space for a foreseeable time.
We first started with a stack of Notion+Airtable but it had huge limitations. Although what we had made might have just worked well for a MVP, we still didn't feel good about it. I showed Reach to my friend/mentor Tony. Tony immediately saw an opportunity to make it in a better way. Being in tech for so long, he felt that the gap between technical and non-technical people on a team is sub-optimal. He thought this was a perfect opportunity to explore if there was a way to easily 'bridge the gap'. We started an experiment called Co-Coding that aimed to hack a non-technical person's ability to a point where they could build a fully functional web-app within 10-12 weeks. As it was a practical experiment, the outcome had to be a usable web-app. The experiment kicked off and an improved version of Reach was born out of it. We are documenting it to help others to cut the noise and jump straight to create usable technical skills. The stack we used to build Reach is Airtable+Replit+Tailwind CSS. You can check out our experiment at cocoding.tonyennis.com.
As this was clearly a large market and that no player in the space had already made it, we assumed that we were the pioneers here. In no time, we discovered that we were wrong - there were around a dozen apps trying to solve the same problem. The problem was most of the platforms were made ages ago and never been updated. They barely had any users, the UI was ugly, not obvious and none of them seemed to have cracked the well known chicken and egg problem of a marketplace. One of them seemed to have done a decent job at making a actually mobile app, but they had missed the point too. This is the kind of platform that people won't open everyday. Even most of the power users would use it once a month max. I intuitively feel this is making users download and uninstall it in no time - after which they have no access to the platform and community. When new users download the app, they see zero activity, or they end up approaching a person who has deleted the app months ago. The cycle keeps continuing and this leaves no value for the user.
Our 3 key approaches in building Reach are -
A) We want to make this platform on the cloud so that people can access the app directly via their browsers. They won't need to download something in their system at all. This would make it fairly easy to access.
B) Provide value to the user right away. If we have a book directory containing 1000 books and a visitor has a keen interest in borrowing one of them, why make them go through a sign-up flow at all if you can connect them with the book owner on the email. (We're still not super sure if connecting people via email would work and might need to have an in-app chat feature in the future but it is still worthy of exploring given a lot of people I know are using email fairly regularly and that email newsletters are now booming - something that could have been never thought of even a couple of years ago. Clearly email as a medium has some hidden power that needs to be leveraged in the right way.)
C) Doing things that don't scale - All the existing platforms have opened their doors to users across the world. A user finds value on a 2-sided platform only if the network has enough critical mass that's useful for them (in this case enough books and active users within their locality). Thousand daily sign-ups across discrete locations is just a noise in this case, creating zero value in the long term while taking someone on a path where they are fooled into believing that something is working. Speaking to users, and observing the transaction work is lost which are so important for any early-stage product to even have the possibility of exploring a product-market fit. Paul Graham has excellently articulated this in his essay - Do things that don't scale. This is why we want to limit the platform to selected pincodes, figure out how to get loads of activity going within a particular region before even thinking of scaling.
I am aware that I could do a 10x better job at organizing my thoughts here but I wrote this under a huge time constraint. I had promised to myself to launch Reach this weekend and apologies if the under-reviewed write up failed to communicate better. I had to shake away the temptation to include more things that I thought were important here and arrange the story in a better way. I plan to write more on each of the little aspects that I talked about here so hopefully most things should be clear later on.