7 Principles That Helped Us Bootstrap a 7-Figure Business

7 Principles I've learned growing Gleam from humble beginnings to a 7+ figure business.

As two founders living in rural Victoria with a distributed remote team, it’s easy to forget that we’re part of something bigger. But the wave of startup activity happening in Australia and around the world often seems quite alien when I consider how we have built and run our company. It seems to be the accepted logic that bootstrapping is for hobby projects. For us, it’s informed our entire operating model.

I'm still not immune to second-guessing our approach when I see huge valuations, raises, and exits. But I’m also proud of the way that Stuart and I do things. Here’s a peek at some of the principles that underpin Gleam.io.

Co-founder stories often begin with a charming anecdote about a childhood friendship that led to business success. That long-developed sense of trust, and comradery, eventually writ large. Stuart and I weren’t like that. We met shortly after he sent me the digital equivalent of a cold call in February 2009.

Here's what I received:

Gleam email that started it all
Stuart's original email from Meetup that I responded to

I was the only one at the time interested enough to shoot him a reply.

Stuart already had a few WordPress coupon sites that were working well, he was able to articulate the concept and show that his idea could actually make revenue (and scale far beyond what was possible for him to make on his own).

He presented a plan to build a large scale coupon aggregation site would list coupons from popular merchants around the world, attracts the user via organic Google searches, the user would find a coupon that gives them a discount, click an affiliate link, and we would make a percentage from the sale – you may remember RetailMeNot (also from Melbourne) who had huge success in this space, they went on to get acquired and eventually IPO (proving that this was a fairly hot space at the time).

We tried to do things a little differently with nifty features (user profiles, price comparison, newsletters, reviews) to differentiate our offering from other sites in the space.

Over the next few months, we worked hard to get a prototype up and running. The weekend we met up to pair on the project was a total disaster - Stuart came to my place and I fumbled for four hours trying to figure out Rails routing to make the URLs look something like:

storecrowd.com/coupons/sitename.com

We were able to laugh about the situation and rejoice when we finally got it working.

StoreCrowd website
Some of our early design mockups, neither of us were that great with Photoshop 😆

Fast forward to 10+ years later and with a very successful company under our belt, our roles are still as they were laid out in that first message. Even though it was Stuart's idea we agreed that 50/50 ownership is the best and most transparent way to flourish and hold each other accountable.

The two of us disagree, negotiate, and fight like a married couple all the time, but ultimately the call is made by the person who owns that area which is tech for me and product for Stuart.

After we’ve put all our ideas and data on the table but still don’t agree we’ll make a decision. We accept that one of us owns that part of the business accept it. Overall, there’s been surprisingly few told you so moments.

Unlike a lot of success stories, we didn’t start with a vision for a world-beating product. We didn’t have an industry waiting to be disrupted. Instead, we had the desire to build something together that makes some dollars. While the single-minded visionary founder makes for a compelling story, our success has stemmed from the need to be very, very flexible in what we’re creating.

StoreCrowd, our coupon site, got to a peak of 5 remote employees and revenue of $45,000 AUD/month. We realised that companies were spending a fortune on coupon sites when they could easily become the top result if they hosted their own.

StoreCrowd Finish Line Coupon Codes
One of the final iterations of the StoreCrowd design

We built Couponzor as a whitelabel product so they could do that. This one never really took off due to the overhead and trust required for a company to get set up, along with a more direct sales approach – which wasn’t really our forte.

CouponZor website
I'll admit that this wasn't our best landing page, but we wanted to validate an idea quickly

Like all entrepreneurs, we wanted to solve the little problems we uncovered along the way. ServerBear helped people to find better deals on hosting by allowing users to benchmark their existing web host and see how it compared against everyone else.

The problem with affiliate deals in the hosting space is that the majority of the hosts offering big payouts for signups (HostGator, BlueHost etc) aren’t the ones that offer the best performance or service.

So, in a way ServerBear was fantastic for the end users, they could find the absolutely best value and performance for money. But, we ended up pushing users into providers that didn’t have an affiliate program or paid us a small percentage for each signup.

ServerBear website homepage
ServerBear allowed users to see individual server plans ranked by various metrics

This idea at its peak was worth around $5k/month. We also built a image bookmark site called Thinng (similar to Pinterest) which saw some decent traction but lacked the ability to be monetised decently.

Thinng website homepage
With every project our ability to execute and confidence grew until we understood what people wanted

The main thing that killed off these early sites (StoreCrowd and Couponzor, anyway) was the Google Panda update. Practically overnight we went from almost quitting our jobs to zero.

Google Analytics Panda Update
Panda killed us almost overnight, then gave us hope again almost a year later only to take it all away once more

We picked ourselves up and decided to focus on building a subscription product so we weren’t reliant on SEO. We had built our own competition forms in StoreCrowd to do some giveaways and created our first competition widget for ServerBear. This was the foundation for Gleam.io.

The startup world looks for growth first and figures out the monetisation later (and profit later still). Stuart put the initial costs for StoreCrowd on his credit card. We spent $2,500AUD on the domain, business registration costs, and a server. We also used off the components (like Bootstrap) and Stuart designed what he could with Photoshop.

We've never had to put more money in. It took a matter of months for StoreCrowd to start paying for itself.

When we started Gleam.io, the competition site, there were many competitors. Our difference was that we weren’t tied to one social platform so users could run competitions on Facebook or Twitter. Users could also log in using Facebook, Instagram, Twitter, or SoundCloud which made the experience more seamless.

Commercial partnerships have also provided both money when we’ve needed it, and the opportunity to do more market testing and refine our core product.

Lady Gaga Artpop
Since our Competitions already allowed users to collect media, building a Gallery add-on was a logical step

In the early days of Gleam.io we built a bespoke solution for the Lady Gaga's ArtPop competition which ended up becoming our Gallery app (which has gone through a few iterations since).

The Gallery app was something we already had customers asking for so it made sense. On the other hand, you can also get distracted by trying to build everything that your customers want. I'd recommend keeping a list of what users ask for a building what you think will add value to as many customers as possible. It's okay say no.

From the beginning, we were both very clear that our personal lives had to come first. For me that means my wife, two kids, and paying our mortgage. My first child was born shortly after we started. Stu has two kids of his own. When we started StoreCrowd, I would get up at 6am and work two hours before my day job. I quit playing World of Warcraft completely. Stu was working even harder by doing evenings and his train commute. When I made my treechange, I did two work hours a day on the V/Line train.

During the tougher times, between the Panda debacle and Gleam making enough to pay me, I went back to contracting. Managing a side hustle as it’s rapidly growing while giving your attention to a day job is a very tough situation. We always ran the numbers and went for pragmatism over optimism. Before going full-time, the company needed to reliably be making enough to pay me. It was a roundabout way to get where we are, but we’re not ‘sleeping in our car’ founders. Our families have to come first (and this is something we should all talk about more).

Gleam Early Growth Data

One thing that worked very well for us was setting a specific revenue goal that would allow us to both quit our jobs and go full time. This was $20k AUD MRR - which took us about 8 months to achieve in the beginning. Despite being in a very good position, I was (and still am) fully prepared to go back to full-time work if we get annihilated again.

Because we don't have to answer to anyone, we're able to experiment. We started as one hand-rolled server and the two of us working part-time without paying ourselves. Now we've got around 30 servers, 18 team members dotted around the globe, and it's all sustainable.

The way we’ve built our team can raise a few eyebrows. There are a few now-traditional startup tropes that we’ve avoided. I never was a fan of meetings so we only have a handful of them per year. We use open salaries which means that our roles are paid at the same rate no matter where the team members chooses to work. We also pay normally, there’s no undercutting wages and topping things up with stock options. We want our team to continue to work with us because they are happy and challenged, not counting down to the day that their stock vests.

Gleam Yearly Retreat
Our yearly retreats are often the only times we see each other face to face

It could be said that we hire slowly but we’d rather call it deliberately. Firing people is a horrible thing to have to do (and 100x times worse for them) so it’s something that we want to avoid. We have fired people before but we made the call that it’s our fault for screwing up hiring. We give 3 months notice which is enough time to find a new job. We maintain a healthy profit margin (~50%), a good reserve of cash, and still only hire when we’re in that range. I could imagine if we had a board full of MBAs they’d probably consider this negligent.

When you start out trying to build a business (or "startup"), it's easy to get caught up in specific ideologies about how a startup founder should work.

In our case, we didn't worry about what others were doing - instead we blacked out everything except:

  • Customer Development
  • Execution of ideas and feedback into production

We did this systematically until we hit the MRR goal that let us both go full time. 8 hours or normal work per day, then 6 hours (or more) of work on Gleam. Just grinding forward as best we could.

There's a lot of distractions in the world. Having laser focus meant we needed to reduce them, ignore them or find ways to optimise our workflow to free up our time to work on the important stuff.

In the early days we didn't attend startup meetups, conferences, or really put much effort into our online personas. To us, that was time wasted from execution and also opened up additional distractions.

The same can happen with your business. Stuart was spending 10 hours a week doing demos for customer, many of which would end up signing up for our $39/month plan. Whilst this may be sustainable in the early days, that sort of approach isn't viable in the long run - so we stopped doing demos.

So many founders/bosses try to delegate as soon as possible so they can focus on important work. In the early days, Stuart spent vast amounts of time every week parsing the data from affiliate networks. We could have simply passed this to a team of remote workers on day one. Instead we felt the pain so invested in automation and improved our user experience. In return we got an intimate knowledge of our data which helped us to optimize our business.

It wasn’t until our backlog of data became impossible for Stuart to manage that we hired staff to manage it.

To this day, the majority of support for our thousands of customer and millions of users is still handled by myself and Stuart. Every morning we get our support inbox to zero and keep it there. If we consistently see an issue being raised, we have full visibility and will endeavour to fix it so it stops hurting us and our customers. Contrast this with most companies (particularly large ones) where issues get stuck in the Customer Support black hole forever (customer raises issue, support replies, nothing improves).

I’m the first person to get a call from PagerDuty if the site goes down and on tools every day (near-constant commits from 2012-2019 on GitHub).

Gleam GitHub contributions

Every week I’ll email a customer back saying, “I’ve fixed that. Thanks for raising it.“. It might sound ridiculous that we spend so much of our time on these tasks that are commonly (and relatively easily) delegated but it’s worked out really well for us.

It would not have been possible for us to even conceive our current company when we started back in 2009.

I started like most people with romantic dreams of my cool startup office (complete with beer on tap, cat, and dog), absurd employee perks, and vast riches.

By constantly challenging our own ideas we've pared back our company to the bare essentials. We only change it after careful consideration and experimentation. To this day, we still don't have an office and may never get one.

Author

John Sherwood

Tech co-founder of Gleam.io from Melbourne, Australia. Former Java dev, current Ruby dev. Big fan of cider, cats, and the Sega Master System.