We reached $5k/month at CampgroundBooking… and it only took 33 months 😳😂

This post may contain affiliate links. See our affiliate disclaimer here.

There are a lot of business articles on the internet that talk about how someone started a new app and within a short period of time, it was raking in ridiculous revenue. Those articles are the Instagram of business advice. Fun to look at, but you never feel good when you click away.

happy good mythical morning GIF by Rhett and Link

Instead of writing one of those, I want to share how long it took for me to reach $5,000/month in my first real software endeavor. The hope of this post is to share some of the realness of what it’s taken for us to build something that’s useful for customers while continuing to travel and maintain our other projects.

And before I jump in, I know $5k/month isn’t a ridiculously high number for many businesses.

But it’s a meaningful metric for us because it’s a goal we’ve been working to for a while. It’s the number that Paul (my co-founder) and I agreed to hit before we started paying ourselves. It’s also the number that, in my mind, would signify that we reached “product-market fit” (AKA the number that would validate that we haven’t been wasting our time trying to build Campground Booking over the past three years).

Note: To be specific it’s not technically MRR because we don’t have monthly software fees, but our reservation fees are currently at $7k/month as of writing this with steady upward trend, so I claiming $5k/month is a fairly safe statement.

On a run with my cofounder & CampgroundBooking CTO, Paul Ryan

Alright, let’s get started.

(These lessons are in no particular order. Some of these are specific to software, others are more of the mindset changes I’ve had to make along the way.)

#1 “Businesses don’t run out of money, co-founders do.”

On a phone call a few years back with my buddy Kevin, I told him that I was ready to go all-in on CampgroundBooking and devote 100% of my time to it. I was excited about the prospect of growing a software business and geeked out to spend more time building the company.

Kevin, being the wise and good friend that he is, offered up some advice. He said that since this was my first go at building an app, it was going to take longer than I expected and that nothing good ever happens when businesses run out of money. The part that I remember him explicitly stating was that “businesses don’t run out of money, but co-founders do.”

This part stuck with me. Since we were bootstrapping, there was a good chance Paul and I could run out of financial runway and have to give up building the business in order to pursue work that actually paid. If I wanted to give this a real shot, I needed to find a way to create additional alternative income streams that weren’t reliant on CampgroundBooking’s success. Basically, a way to still put gas in the RV while we were building out our product.

That’s exactly what I did.

In the past few years in addition to spending a large chunk of time on CampgroundBooking, I’ve taken on client projects, sought out sponsors for the podcast, hosted a few conferences, and done a lot of other projects to continue paying the bills while still working on this longer-term goal of building a software company.

If I’d tried to go all-in a couple of years back, I would have burned out and so would our bank account.

#2 “Don’t trust customers who aren’t paying money yet.”

So far my first two takeaways are just quotes from friends who have also started software businesses, but that’s okay. This one comes from my friend Nathan Barry at ConvertKit, who shared this on a podcast episode we recorded together awhile back.

Before we built a property management system for campgrounds, I took some of our early mockups around various RV parks we were visiting and sought feedback from owners and employees. I told them I wanted to build an app that would allow us to easily book campsites online and also give them a simple way to manage their property.

Screen shot from our new website I built last month. 

We didn’t yet know how we were going to charge, how our product was different than their existing property management system (if they were using one at all), or much at all about running a campground.

Everyone seemed to come to the same conclusion: there was a need for a centralized reservation system and an easier way to book campsites.

However, this was obvious from the start. Talking with prospective customers didn’t provide a clear direction. Instead, it was confusing and caused analysis paralysis. When I pitched various campgrounds on potential pricing models, I received conflicting advice. Some parks preferred to pay a monthly software fee and other parks were open to the idea of a small reservation fee.

The more I talked with people, the less clarity I had moving forward.

What I learned was that if someone hasn’t solved a pain point in a market in the way that you’re hoping to, everybody is guessing just the same. It’s important to take in qualitative feedback as data points, but at the end of the day a decision has to be made so you can just move forward.

Once customers started giving us money they became vested in the product and their advice was invaluable. Instead of guessing what to build, we had customers pulling us in a very specific direction…and a nice list of features for Paul to create landed in Jira.

#3 Focus on a customer’s actual pain point (not a perceived one).

For the longest time when I pitched customers, I tried to sell them on my pain point. As an RVer, I desperately wanted to reserve campsites online and felt campgrounds would share this frustration with me. They did not.

Many parks I spoke with actually were full (very full).

Snapped this photo at a campground in Jasper National Park last year. They were so packed that we barely could fit into the overflow lot.

Switching to a new software would require a change in existing processes, which was more of a pain than my perceived benefit of booking online.

Last summer when Alyssa and I visited multiple parks across Canada, I started to realize how we could actually help campgrounds.

RV park owners with zero online reservation capability were spending anywhere from 5-20 minutes fielding each booking through email and phone. This added up to thousands of hours per year doing something that can be fully automated in as little as 60 seconds online. On top of the lost time, they often were collecting credit card information over the phone or online (which is really not secure for us campers).

Then it hit me.

The pitch wasn’t to “help campgrounds get online.” This is not a pain point for many parks (at least not one they perceive). The pain point is that campground owners are spending hundreds of hours on phone calls and emails fielding bookings and CampgroundBooking can save them time and money.

On a call last month with a campground, we calculated that by transitioning to online reservations, it would save her $15,000 per year. Plus, she could spend more time working around the park and interacting with guests.

Being able to help someone save actual time and money is a very real value prop.

Now when reaching out to potential customers or writing copy on our website, I focus on how we can help solve one of their main pain points (not enough time in the day to do everything) through our solution (simple campground software & automated online bookings).

4. Just because I can’t code, doesn’t mean I shouldn’t be focused on improving our product.

My co-founder Paul can build just about anything. I put together some Ikea furniture a few months ago and it took me the better part of a day. Then I realized I put the top part of the dresser on the wrong side.

When I imagined growing a software business, I assumed Paul would spend his time focusing on building out our product and I would go and sell it. And while it has worked out like this to some extent, I’ve found that I can play a meaningful role in improving our product, without touching a line of code.

Here are a few ways I’ve been able to help support Paul in improving our product:

Product Roadmap Direction

When our application was still in beta, I spent a lot of time talking with potential customers. After each call, I would draft up notes to share with Paul on feedback I’d received (i.e we need to integrate with Quickbooks or provide a specific kind of report for campgrounds).

The struggle of bootstrapping is you have hundreds of feature requests and can only focus on one at a time. Since there’s always new features being requested, my job is to help Paul prioritize the most urgent ones and then work with our designer to bring them to life. (Side note: learning how to create a good design brief for how features should look and feel has been a lot of fun!)

QA Testing

In addition to passing along feedback from new customers, each time a new feature is pushed to staging — I (along with Paul) are both our testers. While we have automated scripts running to catch little bugs and Paul does his best to catch them, I work hard to try and break stuff before our customers do.

Support

Earlier this year we had our largest campground ever go live at 12:00 AM Pacific time. This meant I was up at 2:00 AM ready to launch. -_-

There was a massive influx of customers waiting up to book, so many so that our servers couldn’t keep up. Paul and I stayed up for nearly 48 hours helping to assist the campground’s customers make reservations.

We could have slept through the night and replied to customers at a decent waking hour, but we wanted to make sure that customers were receiving responses as soon as possible. This let our campground know that we weren’t just providing a solution and sending them on their way, but we actually were a partner in helping them succeed.

The whole experience was exhausting, but it helped create trust and a better product experience.

Learning to provide good support has enabled us to keep early customers happy while we continue to build out an amazing product.

Here are a few specific ways we’ve tried to provide good support:

First, we use Helpscout to track all of our support tickets. Helpscout integrates with Slack, so we also are notified when emails come in and then we can run reports on important metrics like “time it takes to initially reply to the customer”. Helpscout also will allow you to manage multiple mailboxes if you have different kinds of customers.

Second, we started taking more time to train parks before going live by setting a proper kickoff call with their whole team. This allows us to dive deep with each campground and cut down on future email and phone support later.

Lastly, a couple of months ago I hired an amazing head of customer support who came to our RVE Summit (shoutout Scarlett!) who has helped us develop even better processes and now a learning base we can refer to as we grow. Having a dedicated and organized person running our support has already made the world of difference.

5. The first five customers will likely be the most challenging.

Our first five customers were hard. REAL hard.

Our product was raw, slow, and lacked some very basic functionality. All the entrepreneurship/startup experts tell you that if you’re not embarrassed about your initial product, then you waited too long to launch. While this is a nice sentiment, being embarrassed about an early product isn’t actually very fun.

However, going live before we were ready allowed us to be pulled forward by our customers telling us exactly what they needed (versus us trying to guess).

Some advice I received from my friend Ryan at Outdoorsy was invaluable when it came to communicating with our beta customers. He said when pitching early customers, tell them you are “partnering” instead of selling a boxed up solution. This sets proper expectations about where the product is and also gives them the benefit of being able to give early feedback for features they’d love. Plus, it took a little of that pressure off to feel like our product had to be perfect.

6. Making $5,000 through a SaaS business isn’t the same as making $5,000 through freelancing.

At a certain point last year, I felt really discouraged that CampgroundBooking wasn’t bringing in more revenue. You can look back on our Stripe dashboard to see this more clearly.

When comparing our lack of revenue to Alyssa’s and my freelance client projects, which often are $5,000/month or \ a similar amount for one video, this was tough. These projects took significantly less time and energy than CampgroundBooking and made way more money. The bigger challenge was having blind faith that one day all the upfront work would have a longterm benefit.

I now realize trying to compare a monthly recurring software revenue to freelance projects is kind of insane.

For starters, with client projects you are constantly having to get more and more of them to sustain your livelihood. CampgroundBooking is a property management application which our customers can use for 10-15 years (which means 10-15 years of potential revenue from one sale).

Second, software takes time to build, especially when you need to build enough features to run an entire company’s processes. Our freelance work is all about using the knowledge and experience Alyssa and I already have, like helping our clients launch products or books. This meant we showed up already having processes in place to make our projects successful.

Lastly, software as a service scales without selling our time. Now that we’ve suffered through the “trough of sorrow“, it takes very little energy to bring on new customers. With our current server set up and team size, we can easily scale to 5-10X our size with very little added costs. With freelance work, you can only scale yourself so much.

7. Don’t defer writing up a legitimate partnership agreement.

This point isn’t software specific but one of my biggest takeaways from the past year.

At the start of CampgroundBooking, we had three co-founders. As of today, there are two of us. Without getting into the weeds of our situation, I’ve learned the importance of being intentional about setting up a proper partnership agreement from day one.

This means that if someone needs to exit the business, there’s a process for doing so. A proper partnership agreement takes a number of factors into account—how to deal with firing, disagreements, valuing the company, etc.

Luckily, we had an amicable transition, but many businesses are not so lucky.

At the beginning of any company, you’re just excited to focus on your idea. Spending a few grand on lawyers to draft up an agreement sounds like a waste of time and resources, but it is absolutely not. We spent way more money navigating the ambiguity of a vague partnership agreement than we would have spent if we’d just hired a lawyer to draft it from day one.

Having a good partnership agreement isn’t just about spending less money, it’s about properly documenting something that will have a major impact on you and your family’s lives, as well as your partners. No matter how happy everything is in the beginning, you want something in writing that will protect everyone involved. A few awkward conversations at day one are better than dealing with heated conversations at year two or three.

If you’re building a business with a partner, don’t skip the step of making sure you have a written exit plan.


I’ve been working on CampgroundBooking for a years now. I remember talking to people about my idea back when we were editing our documentary in early 2016. Now it’s halfway through 2019 and I finally feel like I have a product that I’m proud of that I know can sell. Kevin was right, it took a lot longer than I expected and if I had tried to go all-in on the business back in 2016, we would’ve run out of money and failed.

Learning how to start and grow a software company is something I’ve wanted to do for a long time. Navigating how to solve a pain point in the market, working alongside a technical co-founder, and bringing our idea to market is invaluable experience that I’ll take with me forever. Even if this idea had tanked, going through this experience has pushed me in a ton of ways and I’m excited to see where we can take this business.