Magicians never share their secrets. But we do. Sign up for our Ruby Magic email series and receive deep insights about garbage collection, memory allocation, concurrency and much more.
For many freelancers and small business owners, moving from consulting or freelance development work to operating a SaaS product is the Holy Grail. That makes sense: running a SaaS scales better and makes for a stable income. While there’s no guaranteed path to success, here’s what we learned taking AppSignal from a “20% time side-project” to a business serving thousands of developers around the globe.
This article isn’t a blueprint. Some of it is very specific to us; our timing, network, and undoubtedly, our luck. Most of it is opinionated, based on AppSignal’s collective experience and my personal experience as a co-founder. Finally, this article covers quite some years and is a recollection of our and my memories. Your mileage will vary.
Back in 2011, we had been consulting full-time for nearly ten years. Over time, our team grew to nine people. The bigger team enabled us to take on more and larger projects simultaneously, but it also meant we had to keep feeding the beast. There’s a need for a constant influx of new work, which requires more people (and so the circle continues). Looking up to Basecamp and others like it, we figured that “something like that” would be amazing. We’d be the owner of the product decisions, instead of our client being the owner of most of them. We’d be paid for value instead of time, and we could do it while sipping cocktails on the beach. Recognizable?
“So far, we had failed three times with the help of others. If our next plan didn’t succeed, we wanted it to be at least our own fault.”
In the past, we were already involved in three different SaaS partnerships. In all three instances, our partners came up with the idea based on their expertise, and we took care of everything technical. We’d build and maintain it, they would sell it, and cocktails on the beach would soon turn into a party.
Unfortunately, we learned that the other party either couldn’t make the business take off (and we couldn’t help because of lack of expertise) or lost interest and walked away. Even though we didn’t know what service to build yet, we knew we would take the lead ourselves, or at least have the expertise to run it solo. So far, we had failed three times with the help of others. If our next plan didn’t succeed, we wanted it to be at least our own fault.
We had built a prototype of a logging service before (something like Papertrail) but believed we needed something that provided more value. Something that wouldn’t have developers search for answers to their questions, but answers questions they didn’t know they had. Meanwhile, we used our custom-built logging solution for our client’s projects, combined with Airbrake for errors, New Relic for performance metrics, and Server Density for host insights.
With information scattered around four platforms, it was near impossible to see at a glance what was going on. We had to mentally piece together data from all four services to see the bigger picture. And then it hit us: what if we build an all-in-one application performance monitoring solution for Ruby on Rails, consolidating the vital information we now dug up from various tools and dismissing the data we could do without?
We’d love to use that ourselves, which often is an excellent indicator of a fitting SaaS market to enter, plus we can build this on our own. How hard could it be?
“To quote from a 2000-year-old book: no one can serve two masters, especially if your job security relies on one of them.”
The consulting business was making money. We weren’t getting rich over it, but surely we could start spending our Fridays working on AppSignal while the work we did Monday through Thursday paid for it. That’s what we did, and it’s how most people trying to make the same transition do it. It’s also the approach that sets most of them up for failure, just as it did for us. To quote from a 2000-year-old book: no one can serve two masters, especially if your job security relies on one of them.
At some point in time, something comes knocking on the door that you can’t pass on. Maybe it’s an incredibly lucrative project. Perhaps it’s you trying to reach a deadline. It’s possibly a client you’re not willing to lose, demanding you spend more time on them. Either way, not spending a Friday or two on your new SaaS can’t hurt; in fact, you’re only raking in more fuel to drive future development of your new product! In reality, this is the exact moment when your SaaS side-gig has started falling apart.
So, what if you just let part of the team do the client work – meeting deadlines and letting the client decide what to build – while some others work on the cool SaaS where they can make their own rules? The answer lies in the question, and eventually, Team SaaS has to help out on client work anyway.
In the end, the only thing that worked for us was cutting the cord and waving goodbye to our clients. It also meant letting go of most of the team, moving out of the fancy office, and searching for easy cash to bridge the gap between consulting and profitable SaaS.
All of that is incredibly hard, and I’m sure we wouldn’t have done that if it wasn’t for serendipity.
A short while before cutting the cord, we had to leave our comfortable office. We knew the lease was temporary, but it was even more temporary than we had expected. Without good private offices for rent nearby, we settled on a shared office for the time being, with a month-to-month contract.
Moving out of the fancy office: ✅
At the same time, we were working on a massive project for a client. It generated about 80% of our revenue, and things were going great until all of a sudden, they stopped paying. We had to get lawyers involved, and in the end, lost the client and hundreds of thousands of euros in opportunity costs (i.e., not being able to charge for some of the hours we had put in, while still paying our team).
Letting go of the client responsible for 80% of our revenue: ✅
We probably could have pushed forward and found new clients, but we had zero willpower to do so with the recent stressful situation still in mind. We wanted to pursue the SaaS business instead. We already had something in the making, and couldn’t keep the team employed anyway (the uncollectible hours and legal fees had drained our bank account entirely, and Thijs and myself were paying the team from our retirement savings). We got the team together, explained the situation, and offered them help in finding new jobs. They all did, and I’m happy they transitioned into their new positions without “downtime.”
Letting go of the team: ✅ (unfortunately)
Slimming down the team meant that Thijs and myself were the only ones left. We could now focus on building AppSignal. (With the help of AppSignal’s then fresh co-founder Wes, who had just joined, and Robert, one of our old employees.)
All of this is highly specific for how things went for us, and not something you can replicate. Whether it’s the situation we were facing, inheriting a large sum of money, getting laid off, or something entirely different: most of the time, something has to trigger cutting the cord explicitly.
“With more money coming in than going out, we started paying ourselves. Instead of splitting the money into four, we divided it based on who needed it the most.”
While we had plenty of focus, we had zero money. The consultancy was broke, and we spent our savings on making sure we paid everyone we owed any money. Wes and Robert worked on the product for free, ensuring their freelancing work and employment elsewhere guaranteed an income.
Thijs started doing some freelance work for some of the old consulting clients. Before, we made 10% of our revenue off of them. With a nine-person team, that wasn’t much, but with Thijs doing some freelance work alongside AppSignal, it was good money. I had been lucky enough to speak at over 15 international conferences in the year prior, which made for enough visibility and credibility to work some fruitful freelance jobs. Of course, this still stole some focus, but not as much as trying to make payroll for an entire company.
To start making some money with AppSignal, we followed the lean start-up rule book and sold the service to people within our network. It primarily validated investing more time in the product, but it also made us a little money to pay for operating expenses. Most importantly, it was great for morale. We were running a SaaS business now!
All four of us were building AppSignal when we could, which was in between money-making work. Meanwhile, the number of customers grew, and so did our revenue. We could have fooled ourselves by saying we were (ramen) profitable, but unless you’re paying yourself at least a living wage, you aren’t.
With more money coming in than going out, we started paying ourselves. Instead of splitting the money into four, we talked about how to divide it based on criteria like “who has the most trouble finding freelancing work,” “who needs the money the most,” and “paying who yields the highest return on investment.” We like to think we can curb our egos, which helped tremendously in coming up with a division that everyone could get behind.
We first paid those who needed to spend more time on making people aware of our existence. In the beginning, we couldn’t afford living wages, but it made sure people stopped worrying about finding new freelance work. We did it like this until we could pay the four of us a fair share.
“Don’t underestimate the power of a reliable team. Running a SaaS solo is hard, but getting into fights with a co-founder you have just met online isn’t pretty either.”
When we started building AppSignal, Thijs and I had already been in business together for ten years. Robert had been with us since his graduation. Wes was new to the team, but we saw each other at meetups and conferences regularly.
Don’t underestimate the power of a reliable team. Running a SaaS solo is hard, but getting into fights with a co-founder you have just met online isn’t pretty either. We never had any of those woes because we initially stuck to the people we knew well. Our next three hires were past employees. Only when we became genuinely profitable, we started hiring outside of that bubble.
There’s plenty we didn’t know about running a SaaS business when we entered APM’s crowded space. We did what we thought was right, using our previous experiences. We kept going and became the growing and profitable company we are today. Though that’s no guarantee for success, combined with our share of luck, it’s working out fine.