My Accidental Entrepreneurship - Running the Business
I have already written about how my accidental entrepreneurship started. If you haven't read those, it might be better to check them out first.
In the early days, I faced countless decisions about running the business. Every step required careful consideration and adjustment.
Building to Sell
Before I launched the product, I had read John Warrillow's Built to Sell. The book's main idea is to make your business self-managing and attractive to potential buyers. I imagined who would buy it and what they would want to see when looking into it. I saw two potential future buyers: my main competitor and the accounting software developers. While I saw a slight chance that my business would get acquired, I wanted to keep this door open.
My other main drive at the time was that I intended to keep my regular job while only stealing a little time from my family. I examined every task that came up more than once and assessed how I could automate or outsource it. As a direct consequence, because I had another source of income, I could focus on longer-term relationships with my customers. More on that later.
Onboarding
After someone registered on my website, I sent them an automatic email about how to install and activate the software and noted that they should never hesitate to call us as soon as they can't figure something out. Meanwhile, an email containing the registrant's details dropped into customer service's inbox so they could check if it was legitimate and prepare to schedule an onboarding call. After activating the program, the customers got a new email containing tips on making the most out of the trial period.
Two weeks after registration, they received a third email informing them they would be billed for the next month and asking them to let us know if they still needed time to try everything. The first part got the procrastinator's attention right away, and they were more than grateful when we extended the trial period for them.
The last automated email arrived the next workday after the 20th of the first month of paid usage. Oddly specific, right? In Hungary, accountants must file the previous month's VAT calculations by the end of the 20th day. In most cases, they worked overtime leading up to that day. But if they used my software, they could finish their work much earlier and be less stressed. So the next workday, they are sitting down at their desks feeling much better than in months before, smiling at the icon of my software with love in their hearts - at least that's how I imagined it - and an email notification appears: "Who would you recommend [my software] to?"
I persuaded them to refer this solution to other accountants in this email. It offered no incentive, like a free month after a new paying registration. Essentially, I asked them to reach out to their competitors and tell them about their newly found treasure that is giving them an advantage. It may sound pointless and naive, but it perfectly fits my vision. These customers belonged to a community and often sought each other's help to decipher new regulations, errors in the tax filing systems, or when they took over each other's work when a client decided to switch accountants. I did not want an influx of new registrants who churn out quickly. I wanted customers who would stick with me for years. My customers understood that if they wanted to ensure I continued to provide this service, it would be in their interest to grow my user base.
Day-to-day problems
From day one, I outsourced dealings with customers to someone with sufficient accounting experience. I wanted to focus on developing the software and the business rather than getting overloaded with customer problems. In the first months, I asked myself whenever I needed to solve an issue: "What can I do to prevent it from happening again?" The answer was rarely the same; sometimes, I needed to change a label on a button, and many times, I had to add checkpoints with clear warning messages explaining what the customer should do differently.
The only issue I couldn't mitigate with an easy-to-use solution was when the core algorithm seemed to fail. I did not want to generate more verbose error messages, as they could have been used to reverse engineer my most sacred business secret. Instead, I built a tool for myself, which I could use to debug what could have gone wrong quickly.
Noticing early signs of churn
It's often said that focusing more on keeping customers rather than acquiring new ones is better. With that in mind, I wanted to contact my users when they stopped using the product before they canceled their subscriptions.
My software was a desktop app, and I took my customers' privacy seriously. So, they had to opt in to send events, and even those were anonymous. Even though it could run without internet access, I could assume that most of the time, it would have a connection, if for nothing else, to download a fresh license every month. The program contacted my cloud-based API at every start, and I stored these occurrences.
I didn't have fine-grained analytics on how my software was used, and I could not monitor sophisticated metrics like processed transactions or client count. But the event above was sufficient to see who started the software a long time ago, and that was my early warning that the customer might churn shortly.
My customer service reached out to those who had been inactive for more than 30 days. They asked whether they needed help and if something had changed and they could no longer use the software. Most importantly, they suggested pausing the subscription to avoid charging for something they were not using. Even though I risked losing these customers, I prioritized the long-term relationship with them. Most of them came back a few months after they could handle what caused them to pause, and they became evangelists of the company that treated them fairly and did not want to milk them out of their last cents.
I did not have CRM software; all my interaction records were in an AWS database. Instead of setting up one, I created a database view (a saved query) containing all the necessary data points and a small script to run every morning. The results were then emailed to customer service in an Excel file. It was a crude solution, but it only took an hour to set up. I regularly came back to decide whether it was time to set up a proper CRM, and I always found something better to do that would move the business forward.
Handling payments
Most SaaS products charge customers through payment processors and require a credit card. Most customers get used to giving away this information, so it should not create much friction, right? This is different in my case, where the bulk of the customer base was over 50 or even 60. They preferred to transfer money every month after they got my invoice. As you can imagine, roughly 20% of them forget it every cycle. It also meant that I couldn't use an existing automatic billing system either.
What could I do to make this as efficient as possible? At first, I created a new database view that showed me whom I should charge on an actual day and added it to the daily query-runner service above. In the first months, I issued the invoices by hand.
Then, as the customer base grew, this work became tedious. I wrote a small program that transformed the results into the import CSV format of the invoicing software. I could have used their API and eliminated myself from the process altogether. Still, I found their API service unreliable; I couldn't query what had already been created, and so on. The fully automated solution would have been too complex, and I was already satisfied with reducing an hour-long task to five minutes.
To update licenses, I first created a command-line program to handle subscriptions individually. Again, it was sufficient for the first few months, but after a while, I utilized the core of my product, the one that matched the bank transactions with the invoices. From then on, this process took only five minutes, too.
Small favors
As the niche was small and I relied heavily on word-of-mouth advertising, I did something seemingly counterintuitive when my customers approached me with individual issues. I solved most of them within 24 hours. The situation was like this: they got a transaction list that had been tinkered with, so my software couldn't read it. I could have said, sorry, we're only supporting the official formats, just like our competitor, who turned down almost every request. I view these differently; it wasn't their fault that they got that format. They couldn't use my software; they certainly couldn't transform the data themselves. My business wasn't about text transformation; it was about helping the accountants carry out a long task in a fraction of the time. So, I would rather spend half an hour tending to that particular customer's need, further deepening the relationship, than working on a new feature or marketing effort.
Reducing churn trumped increasing new signups again.
Conclusion
Running my business has been a journey of continuous learning and adaptation. By focusing on automating and outsourcing tasks, I maintained a balance between my regular job and entrepreneurial pursuits.
Effective onboarding and personalized customer care were crucial in building strong, long-term relationships with my users. I implemented systems to detect early signs of churn and proactively addressed customer needs, ensuring they felt valued and supported.
Prioritizing retention over rapid expansion allowed me to build a stable and enduring customer base. This journey has shown me that the key to sustainable business growth is consistently meeting customer needs and maintaining high service standards.