How We Bootstrapped: The Nitty Gritty

The first year of a business can be the most precarious. You don’t know if things work. You don’t know how you’ll pay for them. You don’t know how it will turn out. So it makes sense that there is intense interest on how companies got started.

I get questions about this often, so I wanted to break it down — with real numbers and cents — exactly how we started.

This is especially the case with people who are trying to bootstrap. Bootstrapping means different things to different people, but in general, it means “not taking outside dilutive funding” — i.e., not taking on angel investors and going down the VC route. Fundamentally, bootstrapping is a form of financing (if the null option), and I find that people tend to talk more about the revenue side than costs. My intent here is to lay out both so you can see how we parlayed one product into another.

Starting with a sure bet

We started out with a little mobile app called What’s Open Nearby — sidenote: later changed to Open Nearby after getting a cease-and-desist from a company with a trademark on What’s Open, fun! — which showed coffee shops and grocery stores that were open near you. Our pitch was you could use it if you needed milk at midnight or coffee at 3am.

The app was an offshoot of a similar app that Mathias had built and launched in Denmark a few years earlier, and had some success with. So we already had a sense that the app would be well-received once we localized it. We decided to focus on the DC area first, since it was where we lived.

For the Danish app, we had about $50-60 a month in server costs. (The server cost varied because it was an EU provider, and exchange rates fluctuate.) That app didn’t have ads, but instead companies paid ~$500 to be added to the app. This only worked because the app got over 500,000 downloads — almost 10% of the Danish population — and was regularly in the top 10 in the Danish App Store. But this brought with it all of the pains of client work, and required a lot of time and upkeep. It also required a lot of sales. Revenue went down quickly after Mathias moved to the US in 2012.

We started working on the US version in earnest in January 2014. (Mathias actually proposed to me via a modified demo version of the app that month.) We worked on it, admittedly not very consistently, for the next few months. We knew the pay-to-be-added model wouldn’t work in the US, so we decided to go the ad-supported route.

Crucial to the launch of the app was a $1,000 AWS credit we’d received as a hackathon giveaway earlier in the year. Due to lag from the EU servers, Open Nearby lived on AWS for its first few months. That removed the financial pain of launching the app without revenue. I’ve often thought about what it means to bootstrap — does it mean you don’t take funding? What about self-funding from savings? What about self-funding from consulting or another product? Rarely do we talk about funding via credits like this. An $1,000 credit isn’t much for an established company but it’s life-changing for a new one. You could say that we effectively received non-dilutive funding from AWS.

We weren’t very good AWS customers, though. I don’t have detailed notes from the time, but it’s clear that there is only one AWS server charge in December of 2013 — $54.48 — that disappears the next month. We switched to Digital Ocean once we realized how expensive AWS would be. (Amazon, if you’re reading this, take solace in knowing that we pay you boatloads of money now.)

Our first launch

After months of retooling the app for the US market, making bug fixes based on the Danish app, building parsers to scape opening hours, and manually emailing and calling local businesses to get their hours, we finally launched the app in October 2013.

I emailed every local journalist I could find and posted on Reddit and Facebook. We got a little bit of positive press from my college’s newspaper, local blog DCist and The Washington Post‘s Express — the free newspaper handed out at Metro stations.

“It’s always boggled my mind why, in this day and age, if I want to [get] something at an odd hour I have to go to Google, think of the store name, go to their website, look up the hours, sometimes even call them …” — redditor whosawiddlepuppy at reddit.com complains about what they admit is a “first-world problem.” Alas, there’s a solution! This week, local start-up Dotsquare LLC unveiled an iPhone app called “What’s Open Nearby?” The free app uses your location to automatically find stores that are open at odd hours when you need emergency milk, sugar or … jumbo slice.

This was a huge win. Cell service was terrible in Metro tunnels in 2013, so a lot of people read Express. Our ad revenue payout for that month shot up to over $500.

We also got a lot of enthusiasm from DC journalists, who were often working late or early and in need of a coffee shop.

Smooth sailing, right?

Keep reading.

Geocodio is born

The main screen of the app was a map with the stores open near you. In order to display that map, we needed geocoding: the addresses turned into latitiude/longitude coordinates.

And we quickly ran into a problem: we could get 2,500 free locations from Google per day. We could only cache the locations and couldn’t store them, but it worked well enough at launch. But as the app started gaining popularity, people requested more stores, and we quickly had more than 2,500 locations. At the time, the only option if you needed more than that — say, 5,000 locations — you needed to have an annual enterprise contract with Google, which from what we could find out online, was in the $10-20,000 year range. There was no pay-as-you-go option, just free=>nothing=>enterprise.

Geocodio was born out of this frustration. We built a rudimentary geocoder just to keep the app going. And as we talked about the app and this problem with other developer friends, they told us that they, too, had frustrations with running out of geocoding and how they couldn’t store the data. Eventually, our friends convinced us to”just slap a paywall in front of it” and release it. We had low expectations, and launched it on the hope that if we could get enough people using it to pay for its servers, we could keep using it “for free” for our mobile apps, and that would be a win.

We put Geocodio on two little $10 Digital Ocean droplets (one database, one web server), and to our great surprise, it blew up on Hacker News. We ended up grossing about $28 our first month, which to us was a smashing success. It had paid for itself, with $8 to spare.

What to focus on?

That $28 was exciting, but it was nothing compared to the $500 a month we’d gotten from mobile app ad revenue.

We had many, many discussions about where our focus should be. Our financial worries were front and center at the time — we had an infant who was just starting daycare, and our budget revolved around that new $20,000/year expense. (For the non-parents, I’ll note that this is a very normal daycare cost: daycare is more expensive than state college in a majority of states. This was a very normal in-home daycare — not fancy by any means.) The cost of daycare was a huge motivator for us.

I remember that I was strongly on the side of sticking with the mobile apps and regarded Geocodio as somewhat of a distraction at the beginning. We decided to focus on what was proven to make money: the mobile apps.

Trying to replicate the success

Feeling that we were on to a formula that worked, we tried to build on the success of Open Nearby with another app with a similar concept from a design perspective, Happy Kitchen, about six months later. Happy Kitchen mapped DC restaurants and showed their food inspection ratings, so if you were walking around the city, you could pick a restaurant based on how clean it was.

Despite positive press, the app launch was a complete failure, and we never recovered from it. We violated one of the canonical rules of development — never deploy on a Friday afternoon. Except in this case, we launched it the day before getting on a transatlantic flight. Unbeknownst to us, we had a bug in the app where it was fixed on a specific part of the city and the map didn’t refresh. (Geocoding again!) We didn’t fix the bug until two days later in a jet-lag-induced haze. By then, our potential users had given up on us.

That taught us the hard way that consumer businesses are tough and fickle, marketing needs to be constant, and that there are no second chances. Our ad revenue became quite variable, and we started missing the payout minimums.

But luckily, by May of 2014, Geocodio was starting to take off. We received a ton of feedback after our Hacker News launch, and made improvements at a rapid clip, adding reverse geocoding, Congressional district and FIPS code appends, and a CSV upload tool all within the first few months. Our revenue was very slowly increasing month-by-month. Crucially, we introduced our Unlimited plan in May of 2014, which was the rocket fuel for Geocodio’s growth.

By December 2014, revenue from mobile apps was a rounding error, and we were fully focused on Geocodio.

(One thing I haven’t mentioned here is that we had $5,000 in consulting income in 2014. I pull it out of the numbers because, while it was income, we weren’t intentionally doing consulting — it was a project Mathias did as a favor to a friend. Nevertheless, that certainly helped pad our business bank account a bit and give us some breathing room, even though Geocodio was profitable from the beginning.)

What does this mean for you?

When I first started working on this little archaeological dig into our company’s past and posted about it on Twitter, something was pointed out to me:

Amy’s article on this is well-worth reading, and the story I’ve outlined here is an example of the Stacking the Bricks philosophy: snowball one project into the next.

(I wish I’d known about Stacking the Bricks in 2013!)

I share this in the hope that it gives you hope. We made $0.20 our first month. And $6 the next. But we kept at it, and eventually made $500, which we could then parlay into $20 for another project — one that we were able to shift our focus to once the initial project started declining and we became aware the difficulties with its business model.

But I also hope it serves as a warning. We could have dug our heels in and continued investing our time and effort in the mobile apps when they started to decline. But we didn’t, and I’m so glad we didn’t fall into the sunk cost fallacy. In today’s terms, we Marie Kondo’ed them out of our lives, and by 2015 we were no longer renewing the domains for them.