Secrets of Successful Bootstrapping from Hubstaff’s Jared Brown

“We’re definitely looking at this thing like a lifestyle business,” says Hubstaff co-founder Jared Brown. These are not words you’d expect to hear from a software entrepreneur, but Brown and his partner, Dave Nevogt, aren’t running your typical software startup.

As an accomplished developer, Brown was used to fending off “annoying” inquiries from would-be entrepreneurs with “million-dollar ideas,” but when he met Nevogt, he knew there was something there worth exploring. “It was a very validated, data type of discussion where he was talking about what sort of traffic he was getting, the number of paying customers and conversion rates of a funnel,” says Brown. “It was like ‘wow, this guy’s not dreaming. This guy is doing.’ And that was pretty cool.”

What Nevogt was doing was running a proof-of-concept experiment with a piece of half-baked, white-labeled software used to track the time and activity levels of remote digital workers. Nevogt was unsatisfied with the bundled oDesk (now Upwork) solution he was using in his own SEO business, and was looking for a way to decouple the time-tracking software from the resource marketplace and its associated fees. He approached Brown about partnering to build the idea out and launch it.

“At the time, I had never used anybody remotely. I wasn’t plugged into that world,” admits Brown. He also had some misgivings about the “Big Brother” aspect of the software, but in the end he was persuaded by the potential of the idea and joined Nevogt in a 50/50, self-funded, all-in startup.

Bootstrapping – Not Just for Beginners

Today, four years after the company was founded, Hubstaff is a strong and growing company with – at the time of this writing – an $80,000 MRR (a metric publicly available via Baremetrics, the platform Hubstaff uses for revenue transparency). But, despite the persistent attention of would-be funders, Brown and Nevogt have chosen to continue bootstrapping their baby – retaining ownership and control as they grow their product and business one feature and one customer at a time.

While it may not be an entirely typical choice in the fast-moving world of software, it’s a choice that makes sense for a company like Hubstaff, which lists freedom, transparency and revolution among their top brand values. But, what powers a successful, bootstrapped company? How has this team been able to continue growing without the financial support of outside parties?

There are, of course, many factors, but over the last four years, Brown has noticed a few specific elements that seem to play a role in Hubstaff’s continued success. He has come to appreciate the many benefits of working with remote teams, to value the lessons learned transitioning from a free beta to a paid model, to be comfortable with his (and co-founder Nevogt’s) short-view approach to planning, and to refine his philosophy about product and company growth.

Minimizing Overhead: Building and Managing the Remote Culture

Hubstaff not only delivers software that manages remote workers, they embrace a remote working culture in their own company. The elimination of the overhead associated with office space is one way that Brown and Nevogt keep operational costs down. Though completely inexperienced with remote working when he first met Nevogt, Brown is now a die-hard advocate. “Dave and I are both huge believers in the remote culture and lifestyle,” Brown says. “In fact, we really only see each other face-to-face when we’re doing something not related to work.”

For Brown, the benefits of remote working far outweigh any risks, most of which he believes are misunderstood. “If you’re afraid of a remote culture, or afraid of hiring people from overseas, then you’ve either done it wrong in the past and been burned, or you haven’t done it and you have misconceptions about it,” Brown explains, adding “It’s really not hard at all.”

Hubstaff has become a thought leader in the remote working space, providing many tips on their blog and more in-depth guides and resources on their “University” page. “Remote working removes so many of the negatives of in-person, on-site working,” says Brown. “We’ve removed the perils of wasted time (spent commuting, engaging in office chatter, etc.) and office overhead.” Which isn’t to say that the Hubstaff team lacks personal connections. “We’re not just a bunch of worker drones communicating only about executing things,” Brown says, recounting a recent conversation he had with a poker-playing teammate about the Red Sox. “But our non-work chatter is microscopic compared to our work chatter.”

Brown admits that getting a remote team working as efficiently as the Hubstaff team requires a smart approach and dedicated people who don’t have a problem with distraction. Brown uses a variety of tactics and tools to keep his remote team of seven or so developers on-track and super efficient:

• Daily Status Updates: Based on a habit Brown developed to document his daily accomplishments for bosses who weren’t totally plugged in to the development work he was doing, the daily status updates are simple emails or Slack posts that keep team members apprised of each other’s focus and progress as well as any roadblocks. “Daily updates are just a bunch of line items and bullet points of what each person did that day,” Brown explains. “It’s so much more efficient than keeping everyone sitting on a call where one person is talking and everyone else is muting themselves so they can answer a few emails. I really don’t want to do that to people.”

• Excellent Documentation: Keeping everyone on the same page and up-to-date can seem a little more challenging for remote teams, but Brown has found that it forces you to really nail your project documentation. “You’ve got to be really good at doing specs,” he says. “You’ve got to make a multi-page specification that is a living, breathing document. It needs to capture the implementation – not like 50% of it or the ‘spirit’ of it, but every detail of tactical implementation.” Brown also recommends making good use of wireframes and mockups, “Don’t leave any room for misinterpretation or assume you’re going to figure things out as you go. That’ll kill you.”

• One Owner: Brown’s process involves following a documentation review kickoff with a couple of days during which the team leaves comments in the shared Google doc, collectively polishing the draft documentation into a finalized version. As collaborative as this process is, Brown stresses the importance of having someone on point, “You have to have one clear owner,” he says. “Somebody who may not have final decision-making power, but who is responsible to run with the ball – get other people involved, coordinate the team and work with them.

Evolving: From Free Beta to Paid Subscriptions

The gritty side of bootstrapping is about getting out there before you’re ready, and then hustling to land (and retain) your initial customers. “When we first released, it was the whole MVP (minimum viable product) thing of if you release it and you’re not embarrassed, then you’ve released too late,” recalls Brown. “We were definitely embarrassed with what we put out there.”

But despite imperfect beginnings, Brown and Nevogt began building a modest user base right away because Nevogt had already done some foundational marketing work – setting up the Hubstaff domain and a little SEO work. The team started off with dozens of daily downloads, and about three months into the beta, they were adding approximately 100 new users each day. For the next six months, the team listened to beta users’ feedback and requests and iterated heavily on the software.

Almost nine months after the initial release, the team began messaging users to let them know that the beta would be closing. Brown would have liked to transition to a paid model earlier, but the long beta was necessary to mitigate the risks of client-side crashes and potential scalability issues.

In hopes of reducing churn, Brown and Nevogt offered beta users some very attractive incentives to stay on. They offered a “free forever” plan that gave each beta user three seats for free, and they also offered a coupon for 40% off for life. “It was important to us to be really respectful of these people who worked through so much with us as guinea pigs,” Brown says. “They gave us a lot of feedback and did a lot of testing and validation for us. We wanted to give back for that.”

However, in retrospect, Brown thinks they may have given too much. “I think one of our big mistakes was being too generous,” he admits. “I don’t think we needed to do that free forever plan. If I had it to do again, I’d probably do something more like 20-25% off for 12 months. We were just so scared about churn.”

Ultimately, the deep discounts hurt the team’s initial MRR figures. They had hoped to hit $4,000 – $6,000 in MRR, but at the start were closer to $2,200 MRR. “We could have started off with better MRR, and that could have helped us,” Brown says. “We could have hired developers sooner to help all of us who were really feeling the burn by that point. As it was, it would still be months from then that we would have enough MRR to bring on any help. Next time around, I would definitely not feel so scared about churn.”

Near-term Planning: Not Exactly Scrum, but Agile

It may seem counter-intuitive, but Brown puts a lot of stock in staying focused on the task at hand. “I think that from a development perspective, I’m always focused on this week’s sprint and lining up next week’s sprint,” Brown explains. “If you start looking out to what we’re going to do in three and then six months from now, those plans are probably going to change drastically over time and your margin of error gets very high.”

Instead of taking a traditionally long view when it comes to strategic planning, Brown and Nevogt do “12-week years,” a productivity concept they adapted from the New York Times Bestseller, The 12 Week Year by Brian P. Moran and Michael Lennington. “So we look at milestones for the current 12-week period, including the metric-driven measurement of success, and then – as we look towards the end of the current quarter – we start planning out what we’re going to try to accomplish for the next quarter. But that’s as far out as we go. We don’t know yet what we’re going to try to accomplish in Q3 of 2016. We’re taking it one quarter at a time.”

This approach keeps Brown and his team focused on what needs to get done today and tomorrow. It allows them to spend less time planning and more time doing – an arrangement that suits Brown just fine.

Growing a Bootstrapped Company the Right Way

But, just because the team takes a near-term view on planning doesn’t mean they don’t have a strong sense of how they want to evolve their product and grow their company. “We don’t set deadlines for things,” Brown says of the way his developers operate. “We work by developer estimates, and we never tell a customer that anything will be done by such-and-such a date. That would be the worst.”

Brown initially came to this approach as a direct result of the bootstrapping situation. “If I had a million or two in the bank and a full-time staff who worked on nothing else, I could probably be more strict about deadlines,” he says. “But, starting out, our team was only working part-time for us. We weren’t paying all their bills.”

Once the operation expanded a little and Brown was able to bring on some full-time developers, he had the luxury of enforcing tighter timelines, but instead made the choice to stick with the kind of process they’d developed in the early days. “We’re much more of the frame of mind that we want quality,” he says. “We don’t want to rush things.”

Which isn’t to say that the team doesn’t stay up all night to put out fires. They do. And it also doesn’t mean that they don’t find short-term manual workarounds for certain customer requests. They do that, too. It just means that they take each new feature request in stride. “This isn’t consulting,” Brown says. “No single customer rules us. We get to decide our pace and push it out when it’s ready and decide what to work on next. Everything we do is driven by the customer, but we decide how and when things get done.”

Ultimately, this approach keeps the big picture in mind. “Features done right are the best way for us to grow,” says Brown. “We can throw a ton of money at advertising, but nothing compares to throwing out a nice, new, big feature that you’ve baked for six or seven months and really did right. It’s a homerun, and people are going to love it when you put it out there.”