Roughly a week ago I read an older Paul Graham article titled "Frighteningly Ambitious Startup Ideas." In one of the paragraphs, he discussed out slow and frustrating email has become, and that there should be a lightweight and task-focused service that focuses on getting email (or not) done quickly. As a college student who gets bombarded with emails every day, I realized I have struggled with this for years and it would be fun to build a similar service that Graham described but geared towards our own personal lives. I reached out to my best friend Wyatt and the same day we agreed to try this out in the hackathon.
What it does
Paperboy is a communication service that focuses the users on being productive. On Paperboy, you can only send two types of content - tasks and messages. When you send a task or message, it will auto-refresh the other user's inbox and then they can mark the task/message as done/read or move it to trash in one click. Some key features we envisioned Paperboy including is the auto-deletion of read/trash content after one week. Wyatt and I realized that the vast majority of our emails are actually useless after we read it, so why keep it?
How we built it
In order to build Paperboy, we used a variety of technologies. We built the frontend on ReactJS, which communicates to our backend - written with Ruby on Rails. Our API is a GraphQL layer that rests between the two. In order to get realtime messages, we used PusherJS and created a channel/socket between our backend and frontend.
Challenges we ran into
We ran into quite a few challenges while building this. One of the primary factors that slowed us down was creating an API query that could load both Tasks/Messages into the user's inbox. I had never built such a query in GraphQL so that did take a bit more time than expected. We also had to use additional front-end logic to ensure we were only showing newly sent messages.
Accomplishments that we're proud of
We're really proud that we had a vision and even though we didn't finish every feature we hoped to build, we still were able to deliver on the features that mattered most - sending/receiving tasks and messages and marking them as read or trashed.
What we learned
It's really easy to overestimate how much you can build for an MVP product. When we started hacking, we made a product roadmap showing what features to be built and how each technology would connect with each other. Once we did this, it became clear that we would need to skip a few features to ensure we could build a reliable product in time. We now know its best to start with the features you rather than trying to build everything you can.
What's next for Paperboy
We're really inspired to keep hacking this. Wyatt and I are going to sit down and revisit some designs and product features and revamp the product and then try to get some friends/classmates to start using it. The best part about our choice to build Paperboy is that it's a product we want ourselves, so we can envision and build a product that will work for us too.