Growing my SaaS from Solo Founder to +1 Employee

Growing my SaaS from Solo Founder to +1 Employee

I felt I should share my experience with how I’ve been working on systemizing the business processes and delegating work, as it is a common challenge that entrepreneurs face in their journey.

Last month I hired Safwan Shaikh, a Technical Support Engineer, as HostiFi’s first employee.

Today, Safwan is already handling over 80%+ of our day to day support tickets and live chats, freeing up my time to work on the development of a new HostiFi website with more features.

He’s been a huge help for our customers and brings a ton of experience from his previous work at Ubiquiti. Often times he will work through support tickets that I had no clue how to fix, and I’ll frequently ask him his thoughts if I run into a weird Ubiquiti issue myself.

But it wasn’t easy getting to where we are now. It took months of work to put together all of the tools we are using, build an internal KB of common support request processes, and roll out new security features to be able to share access as a team to all of our systems in a secure manner (2FA as one example).

The months leading up to hiring Safwan were very stressful for me personally, working a ton of hours, and starting to experience some feelings of burnout and even depression, despite, or in some ways because of, incredible growth for the business during those months.

I achieved the goal that I set for the year early. In July I reached $100k ARR, and I was interviewed on the SaaS Club podcast and Indie Hackers. But the support side of the business was beginning to consume all of my days, nights, and weekends.

I had a breaking point when I went on a 5-day camping trip in August.

It was supposed to be a time for me to relax and refresh, but instead, I felt a lot of stress and anxiety being away from my office.

A few memorable dramatic moments.

  • The script that builds the servers got jammed up while I was on a ferry to Mackinac Island. Customers had made server purchases and the orders were stacking up because the script was stuck, and I was urgently trying to rewrite it from my iPhone so that they wouldn’t cancel.
  • A customer’s server became corrupted and he needed it restored from backup urgently, so I was sitting in my truck at 11 pm waiting for the backup file to transfer down to my laptop for several hours over a weak 4G cell connection so that I could restore it.
  • A new customer forgot his password and needed it reset but I couldn’t do it from my phone and had to wait a few hours until I could get back to my laptop. He was furious.

I wrote a bit about that in my August update on Twitter.

I came back from the camping trip with a sinking feeling of failure. I enjoyed my work but I had created a business that demands more of my time and pays less than my last job. I shared my frustration to the mentors and founders in our private Slack channel at Earnest Capital.

I guess this is what happens if you are lucky enough to create a business as a solo founder that has strong market demand. It will eventually completely consume all of your time. Once that happens, many first-time business owners will do one of two things.

  • Retreat back down to where the business felt comfortable — whatever this means to you. Stop accepting new customers, increase prices to slow the growth, slim down. This is Paul Jarvis’s Company of One ideology. Build a business that fits into your life and don’t keep chasing growth once you’ve found some sort of comfort zone or balance that you’ve defined.
  • Push forward, hire employees, grow, and face the pain of everything that goes along with that — training, systemizing, creating processes, figuring out how to delegate work, managing people, taxes, payroll etc. This is E-Myth Revisited ideology.

There’s no “right” answer, but for me, I knew what I had to do. I needed to systemize the work I was doing each day, then hire in order to scale this up.

I recognized the problem and solution, but I had no idea how I would do it.

How could I possibly teach someone everything I know? If they knew how to do everything, how could I even afford them?

After reading E-Myth Revisited, it completely identified the problem I was feeling and had the answers.

I didn’t need to hire another “me”, I needed to create clearly defined processes in the business for every situation that comes up. The processes needed to be so well documented that I could hire almost anyone and they could quickly pick it up and produce the same results each time, with only a limited knowledge of how the underlying components actually work.

Sounds great in theory, but what does that actually look like for a real business like mine?

I worried my business was too complicated to be simplified into easy processes to follow for every situation. After all, we’re not baking cakes here, we’re managing hundreds of Linux application servers.

If a UniFi server isn’t loading, there could literally be a hundred reasons why— ran out of disk space, MongoDB crashed, Java crashed, DNS issue, ran out of memory, needs a hardware upgrade, a UniFi bug is spamming the database with alert notifications on one of the sites, the list goes on and on.

It takes someone who has many years of IT experience, specifically with Linux servers and Ubiquiti software in order to be able to correctly diagnose and solve these kinds of problems right… or does it?

It’s impossible to make a simple process to follow for something that complicated right… or is it?

What if I documented how to identify each and every potential problem, and how to fix that problem, even if there are a hundred potential problems and solutions?

Well, that’s exactly the plan. For any possible situation that comes up, we are documenting how to identify the problem and creating step by step instructions to solve it, even that means creating 100 different guides to solve a problem like “UniFi not loading”.

So how do I go about creating all of these situations so that I can make instructions on how to fix them? The answer is, I didn’t. I waited for the problems to come up, then documented how I fixed it for next time.

Here is what I did for a few weeks in September.

  • Every time a support ticket came in, I recorded my mic and screen with Zoom and narrated while fixing it
  • Saved the video to Notion with a descriptive title
  • Later I started to recognize patterns in both the frequency of certain tickets and my process in how I was solving them, so I created step by step written documentation for the more common problem and solutions

The most interesting part to me was that I didn’t know I had processes at all, but I did. The work I was doing felt kind of instinctive and specific to each ticket at the time, but as I stepped back and literally watched myself solve similar problems over and over, I realized I was checking this or checking that to identify the problem, and then applying a repeatable solution to it (oftentimes just from memory). That was when I realized it was going to be possible to document a step by step process even for something very complicated like how to troubleshoot a down server, it would just take a lot of time.

After hiring Safwan, he watched all the videos I made. When a ticket came in that was similar to one I had already recorded solving, I sent him the support ticket and the video guide and had him try it out himself. I would be available to help or screen share if he had questions or got stuck.

Thanks to the experience he had already, he was able to pick it up very quickly and before long he was proactively taking on tickets that he knew the solutions for. Whenever a ticket came in that he didn’t know how to handle, I would create a new guide once, and he handles it every time a similar problem comes up after that.

He also worked on creating written guides for some of the videos I had made, and this week he even wrote his first guides on his own.

We set up some saved replies in Intercom for super common questions as well.

We’ve also been making external-facing KB articles at to help customers.

My goal is still to create a business where the customer is not dependent on support for anything, but have people standing by ready to help if needed anyway.

That means I still have a lot of work to do. I’m still going to build the new website with all the self-service features where the customers will be able to do common tasks like SSL installation, reboot, changing datacenter locations, restoring from backup — all automated without waiting for support.

But for now, we’ve scaled up to do it with humans and internal processes instead of code.

As our internal and external documentation gets better and better, we’re not just going to become human robots who follow guides though. We still need smart people like Safwan. Instead of wasting brainpower solving similar problems each day on the fly, our team will follow the guides we wrote or other team members wrote to quickly recall a process and apply a solution.

The brainpower of the team will be used for creating new guides, improving existing guides, and finding more efficient ways of solving problems at scale rather than focusing on individual problems.

As we grow, the team will continue to be 100% remote. The work will require strong critical thinking, and excellent written communication skills.