$9,207 Spent, 400 Users: 8 Lessons From Hardcovers First Year

First off, I'm sorry for the length of this post. 😅 It started as a look at our expenses but then ballooned into an article about everything we learned during the first year of building Hardcover. I thought I'd repost it here on IndieHackers because it touches on a number of questions I had when we started. I hope you find it useful!

Also, this post was for our newsletter and our existing audience with the hope of getting them to join our Patreon. If you have any recommendations on how to grow it, I'd love to hear it in the comments.

As of today, it’s been a year since we officially started working on Hardcover! I wanted to use this milestone to pull back the curtain and share what expenses look like for the first year of a bootstrapped startup. That also includes how we got here and what we’d do differently if we were starting from scratch tomorrow.

I hope this article is a guide to how to build a startup you love working on during your first year. This isn’t about how to maximize revenue or optimize A/B tests–there are better posts for that. This is an article about how to build products people love, build a team you love working with, and set up your startup for long-term success.

If you haven’t been following Hardcover’s journey up to this point, here’s the tl;dr to get you up to speed:

• We’re building a book tracking and discovery site for book lovers to replace Goodreads and cut one more Amazon service out of our lives. You can read why in our manifesto or dig deeper with our 13 Reasons Why We’re Building Hardcover article.
• We share our income and expenses monthly.
• We’re not taking outside funding. Instead, we’re using the Slicing Pie model for equity to help spread ownership amongst those working on it, and plan to give away half of Hardcover’s after-tax revenue to causes that support reading (and yes, we do mean half of our revenue, not half of our profit).
• We’re a team of 1-person full-time (me) and 5 people part-time putting in <10 hours a week. This averages out to about 50 hours a week of work on the project.
• The team includes a Product Manager/Full-Stack Engineer (me), UX Researcher/Content Specialist, a Designer/Front-end Developer/Marketer, a back-end developer, and a front-end dev.
• We’re funding the initial development from our own wallets and through Patreon (which we’re just launching today!).

It took us a year to get here. We’ve held bi-weekly team meetings, collaborated on video chat, Miro, Figma, and Discord, and pushed a little bit farther forward each week.

Looking over what would become Hardcover’s social features.
We’ve hit a bunch of milestones along the way:

• Day -7: Jokingly Tweeted about creating a Goodreads alternative out of spite for Amazon. I couldn't get the idea of out my mind and decided to see if anyone wanted to build it with me and posted it on the /r/cofounder subreddit looking for people.
• Day 0: With 5 people interested, we kicked off “Untitled Book Site Kickoff & Sprint” with a brainstorming session about what we’d like to do together.
• Day 14: Decided on a name (Hardcover), registered a domain, put up a landing page, started collecting emails, and began growing our Twitter & Instagram audiences.
• 3 Months: Released a rough internal MVP with the ability to sign up, import books from Goodreads, change your status on a book, and manage lists.
• 6 Months: Released a more polished MVP to our Discord and newsletter.
• 9 Months: Released our public beta with social features (social feed, profiles, friends, private/public/friends-only books).
• 12 Months: Currently iterating based on beta feedback!

After 12 months the feedback we’ve gotten is that we’re a rough replacement for Goodreads. We’re missing a bunch of data, we lack a mobile app and there are limited ways to discover new books outside of the feed. But with each iteration, we’re a little closer. We don’t have a set date on when we want to be out of beta, but I’d hope within the next year.

You might be thinking: “Only 400 users in the first year? Sounds like a failure.” Well, here’s the thing: we have enough users that we’re getting a lot of great feedback, and we’re able to iterate on the product and continue building it out.

There’s a bunch of initial leg work to create a book tracking platform. Loading in data from thousands of books, authors and series, creating a Goodreads importer, and building the actual site. Not to mention a mobile app–something that we realized was needed from the start. This first year has been focused on building out those big pieces one by one.

If we had 10x the users at this point much more of our time would be spent keeping everything working with much less time building it out. I see why so many startups use invite codes to limit new users. Sometimes small is fast.

A Year of Spending

With that out of the way, let’s take a peek at what we’ve spent over the last year. Our Income & Expenses page breaks down what we spend each month, but not where that money is going.

Expenses By Category

So how does a bootstrapped company spend $9,207 in a year? Let’s break it down in a few different ways starting with a high-level category.

• $5,410.78 - Hosting & Site Operations (Website, database, image hosting, API, etc).
• $2,253.81 - Services & Tools (Figma, Noora, Typeform, Termly, email etc)
• $1,020.00 - Operational Expenses (Toggl, Stripe Atlas LLC, legal, etc.)
• $523.07 - Marketing Expenses (Sticker giveaways, merch, etc.)
• $0 - Payroll & Outsourcing (Paying employees and contractors, etc.)

Total: $9,207.66

We haven’t spent any money so far on payroll, advertising, or legal fees. That will come in time, but there’s no need to do it yet. We’ve managed to create a lot from this.

Is this good? I have no reference. It’s the most money I’ve personally ever spent on a project. Every project is different and unique based on the skills and time of those involved. In our case, the skills of the team are focused on building user-focused products. We’re paying for services that help us learn and iterate.

Since we’re bootstrapped, these costs have all been paid by the team working on it. My wife and I have covered $8k+ of it so far, with the rest pitched in by the team.

Repeating the Common Startup Advice

When it comes to startups there are two pieces of advice that get thrown around often:

• Validate your project as quickly as you can. This advice almost usually involves getting to a certain number of users or getting people to pay you money.
• Don’t fund your own project. You’re already risking your time, let someone else risk their cash.

If you just look at the numbers ($9,207 spent and 400 users), we’re failing at both of these. In our eyes, we’re not. Here’s why.

Validate your project as quickly as you can

There’s a shortcut to validation: are others doing it successfully? If yes, then the idea is validated. The big question then is if you can do something different enough that people will switch.

That’s been our big question. It’s a difficult one to know you’ve answered it until you get overwhelming support. We have overwhelming support at the prototype level for at least one differentiator. We’re starting to build that one out and we’ll see.

Competitors are another form of product validation. StoryGraph, another great Goodreads alternative, is set to hit 1 million users very soon! There’s no better validation than seeing a project with a similar vision do so well. Yet, when we talked to users from other Goodreads competitors, there was still something missing. Solving the problems mentioned in those discussions is what we want to focus on.

Side note: we’d all be extremely happy to see any site take market share from Goodreads. If that’s us, that’s great. If not, we’ll keep rooting for all the other underdogs until one breaks out as the clear winner.

Don’t fund your own project

There’s a huge difference between spending $9k on small expenses versus having employees on the payroll. The thought of paying people in cash from my pocket (as opposed to equity) to work on Hardcover while we’re still pre-revenue and without outside funding absolutely terrifies me. If we were going that route we’d take funding for sure.

There’s still an elephant in the room:

How long and how much money would we personally invest in this project before it starts making money or we stop paying the bills?

For a project like Hardcover with a slow path to success, lasting long enough to grow is key. One of the reasons why there aren’t competitors to Goodreads is because it takes years. We knew that going into the project. We weren’t going to launch an MVP and see people flock in. We knew it’d be a long game involving years, a struggle to find a differentiator, and a large focus on search engine optimization.

While this isn’t a question I know the answer to, I feel like we’re just getting started. I can’t imagine not giving Hardcover at least a few years of my life. To give some background as to why I need to share a little about myself.

👋 Hi, I’m Adam the founder of Hardcover. I’m 39 years old and live with my wife Marilyn (who’s a part-time co-founder on Hardcover) and our 13-year-old dog Lily here in Salt Lake City, UT.

I spent my 20’s and early 30’s working at enterprise companies and startups before joining Code School (Rails for Zombies, Try Ruby, etc) as an early employee helping to teach people how to code. I absolutely loved it there and learned a tremendous amount from Gregg Pollack and the rest of the team.

One thing I learned during this period was how amazing it is to work with people at the top of their game at a startup that’s both profitable and hasn’t taken funding. We were a team of developers building educational content for other developers and loving it! I mean, listen to this jingle from a course I worked on:

When we started Hardcover, my hope was to recreate that feeling. We would create an environment for book lovers, built by book lovers and owned by book lovers. It wouldn’t be owned entirely by me – it would be owned by whoever worked on it (proportionally to their work). It could outlast me on its own and wouldn’t be built with the goal of being acquired. One that was designed from the start to be user-centric years into the future without investors constantly nagging for a return.

When Code School was acquired in late 2017, my small slice of equity was suddenly worth something. I had a sudden ~$300k windfall and a bunch of equity in Pluralsight (a private company at the time). There were no golden handcuffs forcing me to stay, but I stuck around another 2 years to help the transition as much as I could.

Six months after Pluralsight went public in 2018 (after the stock trade embargo ended) those shares were worth something and I was able to cash them out. I decided to leave Pluralsight around then and slowly sold off most of my shares over the next year.

The total value of those shares ended up being a little under $1 million before taxes. It was the kind of life-changing startup story I had only dreamed of. It was the kind of money that would allow me to pursue other creative projects on my own.

After I left my job in 2018 I slowed way down. My main project was a blog that helped people learn how to invest confidently without being taken advantage of. I’d started it years earlier after a $100k inheritance when my mom passed away when I was 23. While trying to figure out what to do with those funds, I realized how many sharks there are in the financial world. I began writing about everything I wish I had known when I switched from living paycheck to paycheck to investing and gave it away for free. I’ve worked on Minafi for the last ~5 years and am still extremely proud of it (An Interactive Guide to Early Retirement and Financial Independence is my favorite).

All this to say two main things:

• I’ve been extremely privileged from a financial standpoint. I don’t need Hardcover to be a major financial success (but it would be nice for it to make enough to pay for itself and to pay a liveable wage for those working on it).
• What I love more than anything is creating products that people love using that allow them to be more successful in their lives. Hardcovers’ goal to “help people read life-changing books” is in line with that too.
  Spending some of our own money to make this happen seems like a hobby more than a business at this point. I don’t want to gamble everything on a project where so many competitors have tried and failed (seriously, there are dozens of Goodreads competitors that haven’t made it). But at the same time, it’s rare to find a project that’s fun, exciting and aligns so perfectly with my own values.

Ask me again in 2 years or when we’ve spent $50k. 😅 If our revenue isn’t at least covering expenses by that point then I’d be concerned about the long-term viability of the project.

Expenses By Payee

Let’s dig more into what we’re paying across the board next – sorted by cost – for all expenses above $100.

• Heroku, Hosting, $3,602.58
• Hasura, Hosting, $1,110.49
• Geckoboard, Services, $652.48
• Toggl, Operational Expenses, $620.00
• Vercel, Hosting, $570.18
• Noora, Services, $413.00
• Stripe Atlas, Operational Expenses, $400.00
• Figma, Services, $395.95
• Sticker Mule, Marketing, $282.31
• Tuple, Services, $200.00
• Termly, Services, $180.00
• RafflePress, Marketing, $159.20
• DataDog, Services, $154.21
• Font Awesome, Hosting, $99.00

All other expenses are under this including $66 for email from Zoho, domain registration for $63 from Namecheap (did you know *.app domains have dynamic pricing ?), and mailing swag to contest winners.

We’re using Google Cloud with Imgix for book covers and user avatars, but so far the cost of hosting those is equivalent to a few coffees out per month. Those costs will automatically scale up as we grow.

Lessons Based on Hardcover’s First Year

Some of these expenses were well worth it; others not so much. A few of them were great, but not made at the right time. Here’s a look at what we learned from this so far.

Lesson 1: Don’t Reinvest the Hosting Wheel

Relevant expense: Hosting: Heroku ($3,602.58), Hasura ($1,110.49) and Vercel ($570.18).

We host the Ruby on Rails app and the database on Heroku. According to Heroku, our database is currently 155 GB (!) which is our largest expense at $250/month ($200 for production, $50 for staging).

The thing about books is that they have a LOT of data. For each book, there are multiple editions, multiple authors, series, genres, subjects, time periods, covers–and that’s before we even get into user-related data.

We were extremely fortunate to stand on the shoulders of Open Library and use their data as a starting point. That helped us start with a bunch of data, but with large database costs upfront.

With the recent security breach at Heroku along with slightly lower hosting costs elsewhere, we’re thinking about moving to Render. I’ve been using Heroku for more than a dozen years and know it very well. Even though Render does cost more, there’s the added bonus of knowing how it works.

While I don’t regret using Heroku, I’d recommend using whatever you know best – even if that means a slightly higher price tag. I’d rather use something that allows me to focus on building than optimizing our costs down to the penny.

I’d also love to move to a hosting provider that isn’t using AWS (Amazon), but right now Heroku, Hasura, and Vercel all use it. Our team currently lacks a DevOps expert, so maintaining environments isn’t something we want to take on. Fortunately, our three hosting providers are in the same data center.

We host the main hardcover.app website (which hosts everything visible to users) on Vercel. Hardcover is a Next.js app and Vercel is made by the creators of Next.js. They also have insane analytics built right into the platform:

When we first started, we would add people to the Hardcover team on Vercel. This was mostly done to use GitHub actions to check each commit and pull request was deployable.

That ended up having a few issues. For starters, since I was the only one full-time, I was the only one deploying. We were paying $20 per person to run these checks. With 5 developers at one point, we were suddenly paying $100/month!

The only feature everyone used was the ability to pull in environment variables from Vercel (which is honestly great. If you know of another way to share environment variables for cheap, I’d love to hear it). I still use vercel env pull to get my environment variables locally, but now I just share those out with the team. It’s more work, but it saves the extra bucks.

We already had a GitHub action running npm run lint as well – which effectively told us the same thing: are we safe to deploy?

If you’re a small team using Vercel and don’t have money to burn, I’d recommend having one person be the deployer and give them access. Also, you don’t need to pay for insights ($10+/month) until you have users actively using your site.

Lesson 2: Focus on the API

Relevant Expense: Hasura, Hosting, $1,110.49

A year ago I’d never heard of Hasura. Now I’m one of their biggest fans, and tell people about them every chance I get.

If you’re not familiar with Hasura, it aims to be the single API for your application. Every API request for Hardcover flows through there. Hasura connects with your database and provides a GraphQL API with create, read, update and delete access. You can also use roles and permissions, to decide what tables and columns different users can access.

We allow readers to track what books they’ve read and want to read on Hardcover. But we also support privacy settings – allowing you to track a specific book with custom privacy settings. There are many use cases for this: not wanting to clutter your feed with books you read to your kids, reading a 🌶️ spicy book you’d rather keep to yourself, or just keeping your personal life off social media.

Hasura allows for this by controlling permissions down to the row level. I don’t need to worry about writing API endpoints that nitpick permissions – Hasura does it for me.

Not every action can be handled by Hasura. For those that can’t be, Hasura delegates the requests to the Rails app. To users, there’s only one API.

Later on, when we implement ElasticSearch to improve our current search, we’ll be able to integrate that with Hasura as well. That’ll mean we can create a single GraphQL API to everything we currently have plus ElasticSearch. Once we to a solid point down the line, I can’t wait to see what our readers build with this API.

Since we’re building a Next.js app with this API, we’ll also be able to use it for our mobile apps down the line. If our mobile apps need additional endpoints, we can create them there and only use them on mobile (ex: authentication).

Oh, and Hasura is also open source so you can run it on your own servers. We’re paying for hosting so we don’t need to worry about it.

Lesson 3: Let the Team See Everything

Relevant Expense: Geckboard, Services, $652.48

Since we’re a distributed team, I wanted everyone to feel involved in the project and have easy access to our data. Geckoboard connects to our database, Google Analytics, and a bunch of other sources to pull in data to a single place. Setting up this dashboard only took a few hours total over the last 6 months.

Geckoboard is $49/month, but we prepaid for a year which knocked that down to $39/month. If you’re working with a distributed team I’d highly recommend it. It’s been amazing for being able to quickly answer questions in a way that shares the data with the rest of the team.

If we weren’t using Geckboard we’d still want to make this data available somewhere. That could be a simple dashboard in your admin. If we weren’t using GeckoBoard, we’d probably add this to Active Admin, which we’re using on the Rails side.

Lesson 4: Figure Out an Equity Model that Encourages Collaboration

Relevant Expense: Toggl, Operational Expenses, $620.00

Getting equity perfect for a startup is impossible. I’ve yet to hear of a case where every employee said they felt properly rewarded. There are always going to be some people working harder than others and getting less equity.

In an attempt to make equity more equal, we’re trying something a little different and using the Slicing Pie equity model. Here’s the tl;dr of how this works:

• Everyone starts with zero equity.
• Instead of getting paid in cash, people are paid in equity.
• Each person has an hourly salary based on their responsibilities.
• People can also get equity in exchange for paying bills and a few other things.

That’s pretty much it – at least until you get into more advanced use cases (equity for equipment, real estate, sale incentives, etc).

The goal of this is to create a company structure where everyone who works hard and sticks around will be compensated the most. Even people who only chip in a few hours here and there can be compensated with a small chunk of equity.

If/when Hardcover makes enough to pay everyone working on it a decent salary then we’ll stop paying people in equity. Whatever the equity split is at that time is when it’s locked going forward.

At the moment I own about 75% of Hardcover, with the rest owned by those who have worked on it the most.

The only reason we’re able to control equity in this way is that we’re all tracking our time and we’ve built up a lot of trust in each other.

This hasn’t always been easy. During the last year, we’ve had ~10 people join the team and part ways. These are people who have been extremely excited to join, but for one reason or another it didn’t work out. When someone leaves the team (without vesting) they don’t keep their time equity, but they do keep equity for cash they put in.

This was a difficult decision, but I’m ultimately glad we settled on it. It allows us to always be ready to work with talented people who can help the project while maintaining control by those who are actively working on it.

If you’d like to know more about Slicing Pie, check out Gregg’s videos on it. My only regret is not tracking everyone’s hours from their first day – something we now do when we bring people on board.

Lesson 5: Get feedback until you start hearing the same thing over and over again

Relevant Expense: Discord, DataDog, Noora, Figma.

Getting feedback when you haven’t built anything and don’t have a huge following is tough. When we started Hardcover, my entire “audience” included a Twitter following of ~3k and ~2k subscribers to my newsletter. Since I’m not a book influencer, the overlap between Hardcover and my audience was relatively small.

That meant that in order to talk to people about this idea we’d need to hunt some people down.

The first thing we did was brainstorm a bit about who we’re aiming to build this for. That might sound obvious, but it’s not! There are lots of readers out there. Would this be for teachers and education professionals? Authors and publishers? Kids learning how to read? Only for readers in a specific genre? Casual readers? Ebook Readers? Audiobook listeners? Who do we want to build for?

As a distributed team we used Miro to brainstorm a bunch of questions to get to the person we wanted to build for. Here are some of the questions we brainstormed as a team:

Persona

• Who is having the problem?
• Who will benefit from our solution?
• What do we know/assume about them?
• What are some relevant facts about them?
• How can you identify them?

Why?

• When/Where is the customer experiencing the problem?
• What is the problem from the customer’s perspective?

At the end of this brainstorm, we had a guess on who we were building for: serious readers. We had also brainstormed a bunch of places these serious readers hang out!

Once we had the who in mind, we drafted a discussion guide in Google Docs. This was a series of questions we wanted to ask serious readers. It focused on open-ended questions like “what book apps or websites do you use? Why?” and “Can you walk me through how you use <x>?”.

While it’s possible to turn these questions into a form and send that to people, at this stage we wanted to have conversations. People open up so much more when you’re talking with them compared to answering a form.

The first thing we did was tap all of our existing networks. That included about ~5k different people between everyone on the team. From there we only had a few that were up for a chat.

Next, we started scouring Reddit. We’d personally reach out to people who posted comments about Goodreads (both for and against) and scheduled video calls. Many more people than I expected agreed to these conversations: about 25% of people we messaged were up for a chat.

These conversations weren’t specifically about Goodreads or creating a replacement for it. The hope was to understand their problems and the problems with the tools they currently use related to reading.

A few things stood out:

The way people used Goodreads was very similar. Everyone we talked to used the same few features on Goodreads. Although there are a ton of features across the site, almost everyone used only a small subset of them.

People weren’t excited about it and they don’t like Amazon. There is growing anti-Amazon sentiment due to its takeover of the book industry, anti-union activity, and the wild wage gap between the CEO and workers.

They weren’t sure what was missing but wanted more. The last question we asked, after digging into their use of Goodreads, was about what was missing. Readers would pause, take a deep breath and take a moment to think about it. While everyone came up with an answer to this question, it wasn’t specifically clear. They felt it was underwhelming and not living up to the potential of what a social book site could be, but it was harder to pin down a single thing missing.

From there we distilled the feedback and discussed it more in our team meetings. We pulled out themes and came up with a hypothesis on what our “core” features would be and what our “differentiators” were.

For application designs and interacting it’s hard to beat Figma. We’ve been using it for collaboration, brainstorming, and even for creating interactive prototypes that we discuss with users.

I used to think I could just jump straight into code and create something amazing. That’s worked before, but only when I knew everything about the problem. With new products there’s so much we don’t know! Being able to iterate at this design stage is essential.

We’re using much of the same discovery process I learned at Pluralsight from Nate Walkingshaw. I think the process is amazing, and recommend his book: Product Leadership: How Top Product Managers Launch Awesome Products and Build Successful Teams.

Here’s how this usually plays out.

Step 1: We have a hypothesis on a problem facing our users or audience. This hypothesis only is possible because of past discussions and feedback from users. Starting this ball rolling often means having EXTREMELY open-ended discussions.

Once we’ve identified a problem, we come up with a Voice of the Customer interview guide. Crafting these questions correctly isn’t easy. They need to be open-ended enough without being too leading.

Once we have this discussion guide, we’ll talk to at least 5-10 people asking them the same questions. We’ll keep talking to people until we start hearing the same feedback over and over.

Step 2: If you weren’t able to validate your hypothesis or identify common problems, it’s time to switch to a new problem. If you were able to, it’s time to create a prototype in Figma that solves their pain points.

Crafting a solution to a problem is one of my favorite parts. This isn’t about creating the application people ask for; it’s about solving the problems that they have. We usually discuss the top pain points from user interviews. Then we’ll do multiple rounds of crazy-eight’s sketching as a team, with dot voting on individual ideas.

In the case of social, a bunch of people mentioned they didn’t add some books to Goodreads because they were too private (the privacy settings mentioned earlier). This feature came about because we talked to people and realized this was a pain point.

Step 3: Show the prototype to people and get their honest feedback on it. Doing this isn’t easy. People want to be nice to you. You need to create a safe space where they feel comfortable completely trashing your idea if it’s not something they love.

Much of this is body language, pauses, and enthusiasm. It’s a combination of listening to what they say and how they say it. It means asking the hard questions.

At Pluralsight, I switched roles from a software developer to a product manager. Rather than coding all day, I tried to have at least 5 user interviews a week (most weeks). As a quiet introvert t took me at least 100 interviews to get to the point where I felt confident. I still struggle to interrupt people to keep them on track.

If you’re not perfect at interviewing people you should still do it. You’ll get better at it, and start seeing themes just from talking to people.

If you’ve never conducted user interviews, my top piece of advice for you: don’t put words into their mouth. Avoid leading questions and avoid asking if someone likes or doesn’t like something. Here are a few sample questions we’ve asked in the past at the prototype step:

• What is your first impression of this page?
• How might you interact with this page?
• Is there anything else you expected to see here?
• What would you want to do next from this page?

None of these questions assume the user saw any particular feature. Sometimes we might want feedback on a specific part of the page, but we’d still start with the entire page at once.

If they don’t love it you can try to understand why then go back to step 2 and try again.

This is an abbreviated version of directed discovery, but it hits on the main points. We would often start coding while interviews were still in progress. Or iterate on the prototype between interviews rather than showing a bunch of people the same one. The end goal is the same though: by the time you’ve finished the feature, it’s been user-tested and approved.

Once a feature is out in the wild it’s time to get feedback from users. We did this through 3 channels:

• Discord – This has been our primary way to get feedback while we’ve been building. We have a #feedback channel that anyone can chime in at, ask questions, or report bugs.
• TypeForm – After some releases, or during discovery, we’ll sometimes create forms for feedback we couldn’t get elsewhere.
• Noora – Noora is a user feedback & roadmap tool that lets your users recommend and upvote features they want to see. It also allows for single sign-on, which is amazing.

We haven’t leveraged the feedback from Noora much at this point. Honestly at this stage feedback from Discord and user interviews have been plenty. If we were starting again, I wouldn’t recommend setting up Noora until you have a solid-sized audience that you don’t have easy communication with on any other channel.

Lesson 6: Cover your liability with an LLC

Related Expense: Stripe Atlas

If you’re just beginning a project, you probably don’t need to register it. When we started Hardcover I wanted to skip as much of the legal side as possible. Since we’re not taking funding, spending $100/hour for a lawyer for a few days could be more than double our total expenses.

I’m a member of the /r/startups Discord and they have weekly free office hours with a few lawyers there. It’s an amazing group, and I’d recommend if you’re looking for an informal discussion with a lawyer (in public).

During one of these chats I received some great feedback:

If you’re working with other people you need an LLC.

At the time we had a team of people working together with handshake agreements but no legal structure. The reason for this LLC makes sense:

If someone on the team commits a crime, all of the people working on the project may be held liable. With an LLC that’s not the case.

After using Stripe for another project, I knew I wanted to use Stripe Atlas for registering. It’s more expensive than some other options, but having it all in the same place within Stripe is beautiful. I’d register my next LLC through them too.

Lesson 7: Find Amazing People to Work With

For the first 9 months, we held a meeting every week. Every Saturday at 8 am MST, we’d wake up and jump on a call with this beautiful group of humans (with some different humans over time).

Most of my previous projects were ones I focused on alone. When I look back at all of those projects, they’ve been fun, but none have been successful or world-changing. They’ve been limited by what I could accomplish.

Once we settled on the equity side, we realized what a super-power it was: Hardcover would be similar to an open-source project, but with ownership. That would allow us to bring people on to help out in areas we needed help with. We debated making the entire project open source, but run into a problem with the database needing to be centralized. We’ve even looked into using blockchain for our database or building something decentralized on Mastodon, but decided against it.

Our team meetings have been packed. We try to keep them to an hour, but sometimes they’ll take two.

We start each meeting with a question to get to know each other. We want to enjoy building Hardcover! We want the people we work with to be friends we’re on a mission with – not capitalists optimized for maximum revenue.

We kick off each meeting with an ice breaker. It’s a question purely for fun to get to know more about each other.

Other ice breaker questions we’ve answered:

• What’s a recent TV show or Movie you loved?
• What’s a place you’d love to travel to in the next year or two?
• What’s a Prompt on Hardcover you’d love to see answered?
• If you could learn one new skill, what would it be?
• What’s a goal of yours for the new year?

The point is just to have fun and get to know each other a little more.

During these team meetings, the main focus is always the same: setting a clear intention for the coming week. We focus on making sure everyone knows what they’re working on and that everyone is getting the help they need.

After this meeting, we release notes about it on our Patreon (we plan to start releasing these notes after our next meeting!). This will include a behind-the-scenes look at what we’re working on, how our research is going, and what we’re focusing on next.

This is also where we’d share some prototype screens that we’re still getting feedback on. If you’re interested in giving early feedback before something has been built, this is the place.

Lesson 8: Let an Ambitious Mission Guide You

This isn’t just startup advice; it’s life advice. Whether you call them goals, mission, or vision, the idea of the same: having a clear picture of what success looks like.

Back in 2020, I stopped going to CrossFit classes. Due to COVID, it was no longer safe and was closed for most of the year. I struggled with how to stay healthy during quarantine and put on more than a few extra pounds. It was only when I set ambitious goals–run a marathon and hike the Highline trail–that my exercise efforts took shape and gave me the motivation needed to put the work in even when I wasn’t in the mood.

An ambitious mission can also help you find great team members. An inspiring mission can bring like-minded people onboard.

When I say ambitious goals I don’t mean “get to 10,000 users” or “launch an MVP”. Those are ambitious, but they’re not a mission–they’re milestones.

Missions are less likely to change over time. Our mission on Hardcover is to help you find life-changing books.

Right now everything we do revolves around that. It’s not about optimizing how much money we make, taking funding from venture capital, or organizing Hardcover to sell to a bigger site. It’s all about helping people read.

If that’s a mission you can get behind, we’d love for you to join Hardcover! You can sign up today, and import your current books from Goodreads.

The best way to keep up while we’re building everything out is to join our Discord or the newsletter.

The best way to support us is to join our Patreon! I hope this post shows that we’re building Hardcover for the right reasons. Patreon is a great way to let us know you support the idea and want to see it succeed.