Looking for Ruby/Rails Cofounder for Goodreads Competitor
Hey hey all!
Last year I started a small but ambitious project: create an alternative to Goodreads to take down Amazon out of spite. It started as bit of joke, but now we have a small team working on (all for equity) a Discord community and around 25k ratings being tracked already.
We settled on a name: Hardcover, and have been making progress as a team. We're in alpha now and are working on social features and data normalization (there's a lot of book data to handle!).
The team right now includes me (Full-stack developer / product manager), a visual designer/front-end developer, a marketer, a front-end dev, and a user experience researcher. We brainstorm things together, validate problems and prototypes with users, then prioritize and begin implementation.
We're looking for a Ruby/Rails developer to join the team that would work with me on the back-end side.
If you're curious about the codebase, it includes:
- Next.js/React - The main application people interact with. Using Tailwind.css for styling.
- Hasura - Hasura provides a GraphQL API to our Postgres database.
- Ruby on Rails - For any backend logic that's not a basic CRUD operation, we send that over to Rails. The Rails side also handles emails, background jobs, data normalization and hitting other APIs.
We've also penciled in a React Native app for down the line.
The Rails app is where you come in. Since most API requests from the React side are handled by Hasura, the Rails side is intentionally small and focused on business logic and data. It also doesn't have any views, which means no Sprockets/Webpacker. It's 100% an API and a backend for organizing book data.
In other words, you wouldn't need to write any HTML, CSS or JavaScript when working on the Rails side (well, except when working with emails, but our designer codes those up).
The Rails Side
Here are all the dependencies in the current app. It's rather small so far:
ruby '3.0.3'
gem 'rails', '~> 6.1.4', '>= 6.1.4.1'
gem 'puma', '~> 5.0'
gem 'bootsnap', '>= 1.4.4', require: false
gem 'friendly_id', '~> 5.4.0'
gem 'good_job'
gem 'goodreads', '~> 0.9.0 '
gem 'google-cloud-firestore', require: false
gem 'google-cloud-storage', require: false
gem 'hashie', '~> 4.1.0'
gem 'kramdown'
gem 'pg'
gem 'rack-cors'
gem 'sanitize'
gem 'state_machines-activerecord'
That's it. I know, it's still small. There are a few test related gems as well:
gem 'factory_bot_rails'
gem 'faker'
gem 'guard-rspec', require: false
gem 'rspec-its'
gem 'rspec-rails', '~> 5.0.0'
gem 'rubocop', require: false
gem 'rubocop-performance'
gem 'rubocop-rails'
gem 'rubocop-rspec'
I use to work at a startup called Code School where everything was in Rails. We depended heavily on Rspec for testing. You'd be writing a lot of Rspec tests as well.
(side note: A few years after Code School was acquired by Pluralsight for $36m, I left and have been working on side projects for fun ever since. Hardcover is the first serious attempt at a large-scale project since then using what I learned helping to grow CS as Technical & Product Director. I'm working on it full-time, but everyone else is part-time).
The entire app is a dockerized monorepo so everyone on the team can run the entire app locally. I've been the only person working on the Rails side so far, which is where there's a bottleneck at right now. With an additional Rails developer to work with we could move a bunch faster!
The Design Side
Although we have a ton of Ruby work for the foreseeable future, if you're interested in jumping into the front-end React side or the React Native side, you'd be more than welcome! We collaborate and sketch ideas as a team before going into Figma.
From there our user researcher creates a guide and discusses them with users to get feedback. Once we feed confident about the route we code it up and release it.
Equity
From an equity standpoint we're using the Slicing Pie Model. This means that everyone (myself included) earns equity based on the work and value they bring in to the project. No one is "awarded" equity for joining. This means you'd earn equity based mostly on either 1) chipping in for company expenses or 2) Being paid an hourly salary in equity.
Everyone's percent ownership of the company is (their earned equity)/(everyones earned equity). With everyone on the team tracking hours and being paid in equity, over time it changes – which is by design. Often times the amount of work to make a successful project is skewed to the people that join the earliest – not necessarily the people that put in the most work or make the largest impact.
This role has both with the opportunity to earn a lot of equity.
Everyone on the team can see everyone else's equity, and I update it monthly for the team to see. Our hope with this approach is to incentivize hard work and sticking around rather than just getting in early.
Sound Interesting?
My hope in showing some of this - our tech stack, our design process, the team, the equity – is that we're making a serious attempt at trying to take down Goodreads (or at least make a viable competitor).
Here's a tl;dr of what we're looking for:
- An experienced Ruby on Rails developer.
- Some Ruby testing experience – Rspec is a plus.
- Able to contribute ~10 hours a week most weeks.
- OCD about data, and interested in creating an optimized book database.
- Interest or experience in React/React Native/GraphQL/Tensorflow is a plus and would give a chance to switch between different areas of the app as needed.
Does that sound interesting? Shoot me an email at adam at hardcover.app and let's talk! 📚
Hi Adam,
I sent you an email
Thanks! Responding to it today.
How much customer development have you done outside of the spite portion for product/market fit? It's overall a great concept to an expiring platform, but I'm just not so sure how you're going to compete with a service that is embedded in the e-reading world.
What niche or problem are you aiming to solve outside of an alternative to GoodReads? Have you talked to authors, reviewers, browsers, and publishers regarding the problems with GoodReads today to prioritize building what matters?
It seems like you have everything else mostly figured out, but even reading through https://hardcover.app/blog/manifesto it's not so apparent what vision you're working towards. Better book recommendation algorithms? Personalized suggestions with a social platform aspect? A modern equivalent? etc?
I'm just genuinely curious because I love the idea. Please don't take this as an insult but rather helping with your goal of recruiting more people towards a common mission. I've done full stack in the past (.NET) but mostly work as a product manager so these are the questions in my head as I read this post.
Lot of questions here, but they're all things we need to work out. Some we have ideas on, while others we're kicking the can down the road on. Let me follow up on each question separately (it'll be a good exercise for me to see which ones we have answers for too 😅).
So far we've focused entirely on customer research with readers and have conducted ~50 interviews or so. That's helped us understand the problems readers are having today with Goodreads. We've based what we're building around the most common reader problems today.
We're still trying to figure that out. It's been interesting working on a competitor to such a nearly universally disliked or problematic site. So many people want a place to discover, discuss and interact with other people around books. That's a very broad problem-space with an entrenched competitor.
The mission I've been using so far is simple: "Help people find life-changing books." That can mean a lot of things.
We have a persona roadmap of who we're planning to talk to next which goes: readers -> editors (power users who would edit book data, not editors in the book industry) -> influencers -> authors -> librarians -> bookstores -> publishers -> teachers. Readers and authors would be the groups we believe would be the primary personas that could use it, but we have a lot to verify with other personas.
It's always tough to convey a mission/vision. It inevitably ends up either being very abstract, or you get so into the details and implementation that you're not getting to the heart of the issue.
In my mind the vision is creating a new home for serious book lovers who want to find great books they'll love and learn from other readers. Most of the readers who use Goodreads only use it for tracking what they read and occasionally seeing what their 1-5 friends on the platform are reading. It's the tip of the iceberg. They go elsewhere to research books – NY Times lists, Twitter, BookTok, friends, end caps at book stores, best sellers lists, etc. Very little book discovery (and even less friend discovery) actually happens on Goodreads - which is just crazy to me for a social platform.
I consider it like Letterboxd vs IMDB. IMDB has been around since 1996. Although IMDB might have more info, Letterboxd has an active user base of film buffs learning from each other to make and share new discoveries.
That's where I see Hardcover fitting in. It doesn't need to be the largest community out there to still provide immense impact for the readers, authors and community.
Features, algorithms, library integrations, focus on UI/UX, and other things we have listed on the hardcover.app homepage are our current guesses on how to get there. Other things are required and people wouldn't even try Hardcover without them (import library, book tracking, mobile app, etc).
Just getting the table stakes down for this kind of project could take a full year (or more).
It still feels like the early days right now. Sometimes it feels audacious to attempt such a large project with an indie team without funding. Other times it feels like the only kind of team that could possibly have the motivation to build something for the community. Either way, it's been a fun project so far. :)
Great project! I have signed up, I need a better Goodreads badly. If you are interested I can share my unmet needs and ideas.
I'm an Infra + CI/CD engineer, and short on time, so can't really offer help, but would love to.
Oh that'd be great! It seems like we're always on the hunt for more people to talk to and get feedback from. I sent over an email for us to connect.
Hi Adam, this project seems amazing!
I started as a backend engineer and worked with Ruby/Rails for 5 years but now I am more focused on frontend engineering/js/ts/react. To be honest, I'm not looking for a job or anything but Hardcover caught my attention as I am interested in this space. If it was an open-source project, I would definitely help!
I'll let my contacts here:
— website: https://iamtk.co
— twitter: https://twitter.com/wordsofteekay
— github: https://github.com/imteekay
Thanks for the interest! Since you're already using Goodreads, you know a lot of what we have in front of us haha.
We've thought about what we can do open-source wise. Although the codebase isn't open, we're designing it API-first from the get go. This means that the website and the mobile are using the same API we'd make available for users.
One of the hopes with this is to make it possible for people to build things using the API for fun - and then we could potentially showcase them.
It could be fun to chat! I messaged you on Twitter to see.
Incredible amount of work, very complete post. I hope you'll find the ideal cofounder - it would be well deserved !
Thanks! It's been a fun last 8 months getting this going. Sometimes that seems like a long time; sometimes it seems like a blink of an eye.
interesting project, good luck with the tech stack.
Thanks. After doing regular Full-stack rails dev, splitting the front-end and the backend to separate apps has taken some getting used to. So far all of my attempts to do SPAs using Rails have been uphill battles, but so far this stack has been mostly smooth – aside from when I need to do complex logic that's very business logic heavy.
Looks like a cool project.
I'm interested in the angle of finding others to get involved - where did you find others to join you on an equity-only basis, IH or IRL?
So far it's been a combination of posting here on IH and posting on the r/cofounders subreddit. I think one part that's helped is being very transparent on the equity and communicating how that works. I've also done forecasts for equity to show how it cold look after 1 year, 2 years, etc. That has helped show how their impact turns into equity.
I wish I could help somehow. I previously launched a side project Uption.io which was one off book clubs focused on specific books (as opposed to clubs that read many books together).
Ohh, that's a neat idea. The more I've looked into the space, the more I've realized how many different ways there are of organizing books, book clubs and just collaborating about books. We've been thinking about eventually doing something in the book club space – but no idea what yet. Be interesting to chat to see how your experience in the space was.
Just sent you my contact info via a DM on the Twitter.
Hi Adam, this seems like an ideal project I’d actually love working on. I’ve been kind of seeking a side project/hustle for a while now but I’ve wanted teammates since I work best on teams. But I’ve been wanting to build something mission driven rather than just another B2B SaaS.
The only problem is that I’m not much of a Ruby on Rails developer! I always used Django for side projects. That being said, I’m a veritable polyglot using Python, C++ and Java at my day job and I’m sure I could pick up Ruby on Rails in a few weeks. I do have experience with Tensorflow though (I work on an AI team) and also building data pipelines.
I’d love to talk to see if I could help put in any way.
@robrose Hi have you worked on python fastapi? Can we chat?
Hey Robrose,
Could you reach out at adam at hardcover.app to chat? We could definitely use help on the TensorFlow.js side. We have somewhat ambitious plans for our use of Tensorflow in the works that might be some interesting problems – and a chance to work together with another tensorflow dev on the team.
Thanks!
Adam
I appreciate the objective and I think replacing Goodreads is an awesome idea. I also want to add that Bookshop.org has paved the way for showing that it is possible to challenge Amazon. I also want to congratulate you on how well it's looking thus far. Good job.
On the tech side, I can't see any argument whatsoever for adding so much complexity.
I know we are all into sponsoring the toolkit of large corporations with their back-end/front-end siloed teams (React/Facebook). But limiting Rails to an API and adding a separate app on the front-end seems like total overkill to me, the kind that could certainly jeopardize a project where people are volunteering their time and where more tech knowledge will be needed to add a basic feature (Hakura/GraphQL/React/Rails, etc.).
Why not go full Rails monolith and use Hotwired?
Thanks! Bookshop.org is doing an amazing job. Super excited to see how much traffic we can direct their way – as well as to local libraries.
I've debated this about 1,000 times in my head. Most of the time I wonder if I'm making the right choice. Doing it completely in Rails would be a LOT more simple for the website.
Time will tell if it's a good decision or not, but here's what led to the decision to use this tech stack.
Based on the customer interviews we've had, we know mobile is going to be critical for the success of the application. We also know that one of the big differentiating factors between us and GR is that we want to make open data a priority (GR shutting down their API was one of the reasons I started Hardcover).
Structuring the app in this way allows us to leverage React Native for the mobile version (down the line... hopefully... we'll see. 😅).
With that in mind, the API we use for the website (which all hits Hasura first), will be the same API the mobile app uses and the same API that end users will be able to use to access and work with their data.
Making it a straight Rails app is much much faster to get things done on the website, but then we'd need to solve those problems down the line. We're attempting to structure our data from the start in a way that it's platform independent to build on for mobile and by the community.
On the plus side, the entire API is provided by Hasura, so we only have about 5 actual endpoints and about 6 triggers that hit Rails. Everything else is on Hasura directly.
I'm with you on the added complexity though. It's slower to create pages in this route than just straight Rails. It may prove a ton easier to make the initial part in rails, create an API, and then provide that for mobile/api access. The hope is that it's work up front to make mobile/API access easier later.
I do miss a lot of Rails though. 😭
I understand.
Just in case you were interested in a separate perspective on this issue: I think maintaining a separate API and integrating front-end and back-end for web is more sensible than the glimmer of efficiency you get by mirroring the architecture of mobile and web.
It is true, there would be some redundancy. The redundancy that you would have is the extra Rails controllers for the front-end. However, the Rails controllers are a lot simpler to develop and maintain than a full-on separate web front-end SPA. That's what you are really trading: you get to remove the Rails controllers, and then you are saddled by having to maintain an SPA.
Further, even mobile apps could follow the web pattern using the Hybrid web view approach (turbo-ios and turbo-android). None of the interactions you are likely to have on the mobile will deviate from presentation of documents. So it seems like a good use case to minimize native only to session management, maybe a native tab bar, and handling the web views.
Anyway, don't let me discourage you. :-) Your team seems well suited to pull this off given what you've accomplished thus far.
Good luck!