Nassim Nicholas Taleb has a name for the opposite approach: Via Negativa. I picked up the term from Antifragile. Subtract first, then see where you are.

How Products Get Heavy

The reflex I see everywhere is the same. Churn creeps up. A conversion rate flatlines. Users drop off at a step. The response is to build something. A new onboarding flow. A tooltip. A modal. A toggle. A smart default. A new pricing tier. Each one addresses a real problem, and each one makes sense in isolation.

But the number of possible states a user can encounter doesn’t grow linearly. It explodes. That pricing page tweak you wanted to make? It depends on which plan the user is on, which depends on whether they signed up before or after the last pricing change, which depends on whether they have a promotional discount, and which behaves differently on annual vs. monthly billing. Five independent variables, each with a handful of values, and suddenly the state space is in the hundreds.

Every time we add something to address a problem, we’re also increasing the surface area for the next 10 problems. And the next team that comes along will add something to deal with those. And nobody stops to ask where the product is actually heading. Everyone’s too busy optimizing their own corner of the funnel.

Why does this keep happening? Maybe because addition is more fun. Building something new is what most product managers were taught the job is about. Ship features! Grow the product, dream BIG! And stakeholders want to see progress. A new feature looks like progress. Removing something looks like retreat. On top of that, most decision-makers sit far enough from the codebase and the support queue that they underestimate the cost of adding something. A feature looks simple from the roadmap level. Second-order effects show up later, after the commitment is already made.

The Leverage Problem

There’s a practical math issue with addition. You spot a drop-off in the funnel, so you design something to catch those users. But that drop-off might be a small slice of overall traffic, and your intervention converts some fraction of them. The net move on the metric is small. Meanwhile, you’ve created a new code path that will need to be tested, documented, and supported indefinitely.

Removing an unnecessary step or collapsing two flows into one touches every user who passes through. The leverage tends to be higher, and the ongoing cost is negative. You’ve reduced what needs to be maintained.

So when the urge is to add, I’ve started asking a different question: what can I remove instead?

The Noise Problem

There’s another reason small additions are unreliable: noise. Say you run an A/B test, measure a few percent improvement, and roll out the winning variant. Sounds solid. But then market conditions shift, your user mix changes, seasonality kicks in, or any number of things happen that have nothing to do with your change. That few percent gain can be lost amid background fluctuations. You’ve added permanent complexity to the product for a signal that might not have been real in the first place.

Subtraction is different. When you remove a confusing step, the flow gets simpler, and that holds regardless of what the market does next quarter. You measure it the same way you measure anything: before and after. Support volume, time-to-value, retention. But the signal tends to be clearer, because you’ve reduced the number of variables instead of increasing them.

What Leaning Out Gets You

A product with less internal complexity can be configured and integrated more easily because there are fewer hidden interactions between features. When a product handles the common cases well and stays out of the way for the rest, teams and customers can build on top of it. When it tries to handle every edge case internally, it turns brittle.

There’s a business case too. A simpler product means lower operating costs. Less code to maintain, fewer support edge cases, less QA overhead. Revenue might dip if you cut a feature some segment relied on. But if operating costs decline faster, profit rises. And a leaner operation adapts faster when market conditions change, because there’s less to retool.

This applies to the customer base, too. I’ve seen it repeatedly: the customers who generate the most support tickets, advocate the loudest for new features, and take up the most product bandwidth are not the ones with the best ROI. It’s often the quiet ones who drive the most revenue per effort spent. When you stop bending the product to serve the high-maintenance segment, you free up time to care for the customers who actually matter and to figure out how to attract more like them.

Filters That Weren’t Filters

I was working on a recommendation system. Customers kept asking for more filters to narrow down the recommended list. Too much irrelevant stuff is showing up. The obvious move would have been to build those filters, and every individual request made sense. But stacking filters on top of a recommendation engine would have added complexity to every layer of the implementation.

So I dug into why they wanted each filter. It turned out the interesting part wasn’t what they wanted to see. It was what they didn’t want to see. And those items shouldn’t have been recommended in the first place. The model was surfacing things it shouldn’t have.

Instead of adding filters to work around the problem, we’re rebuilding the recommendation models from the ground up. It’s more work than slapping on a few filter dropdowns. But the feature request was “give us more filters,” and the real answer turned out to be: stop recommending things that don’t belong there. Fix the root cause, not the symptoms.

Scalpel, Not Axe

Subtraction done badly is just as destructive as addition done badly. You don’t walk into a product and start ripping things out. You plan it. You map the dependencies, understand the second-order effects, and figure out what breaks and what gets freed up.

This is not a junior PM move. Knowing what to remove requires deep familiarity with the product, the customer base, and the business model. There’s no checklist for it. It requires the kind of judgment that comes from having seen what happens when things go wrong. Both from adding too much and from cutting the wrong thing.

Pitching Subtraction

A stakeholder comes to you with a feature request. They’ve thought about it, maybe even sketched it out. Telling them “actually, I’d rather remove something” is not an easy conversation.

I often go back to first principles. The stakeholder doesn’t want the feature. They want the outcome. So I dig until we get to that. What’s the actual problem? What does success look like? Sometimes this takes multiple conversations, because the first answer is usually the surface-level one. The real need is often buried under assumptions about how it should be solved. Once there’s common ground on the outcome, it’s easier to jointly explore how to get there. “Remove complexity” becomes a viable path, not a threat.

Sometimes they push back hard. They want the feature, and they don’t want to hear about alternatives. When that happens, I don’t force it. I lay out the implementation cost honestly, including the planning overhead, the edge cases, the regression testing, and let them weigh it against the expected benefit. If all of that still doesn’t shift the conversation, there’s always escalation. Not as a confrontation, but as a way to get a broader perspective on whether the product should be getting heavier or lighter. That’s a strategic question, and sometimes it needs to be answered at a level above a single feature request.

The Bigger Question

This approach isn’t intuitive, especially in product work where the expectation is always to ship more. But I’ve found that the most useful thing I can do with a complex product, whether I’m part of a team or running the whole thing myself, is to step back from individual feature requests and look at the big picture. What are we actually trying to achieve? What’s the real north star?

And then ask whether we even need to build anything new, or whether we need a better foundation to get there, and whether removing what’s in the way is the right move. Sometimes the answer is to simplify everything, accept a short-term revenue hit, and end up with a product that’s cheaper to run, easier to adapt, and ready for whatever the market does next.

Dare to question what’s already there. Remove what isn’t necessary. Make room for what is. Via Negativa.

The dreaded plateau

At the outset, the business was thriving. The monthly active user (MAU) count steadily increased, with occasional exponential jumps. Our trial conversion rate (TCR) was consistently above 50%. However, the first sign of trouble appeared when our MAU decreased slightly, and our TCR dropped below 30% for the first time.

I was prepared for a potential setback as I closely monitored my biggest competitor’s moves. They made a significant shift, abandoning their previous expensive pricing model and creating a new one similar to mine, with the lowest tier matching my price. They could offer additional features because they are directly integrated with the accounting software. Other than that, our value proposition was the same.

At first, I hoped that it was only temporary. My customers and potential customers may try the other product but won’t be satisfied enough to stick with it.

As mentioned in my previous article, I was at a considerable disadvantage on the marketing side. My competitor’s ad was shown after every update in the accounting software, and they could send direct emails to the whole user base. They started to use it more intensively.

My TCR recovered to the previous levels. However, the number of new sign-ups decreased, and MAU remained constant.

I was looking at my analytics and saw the plateau forming. It’s one of the worst things an entrepreneur can see. Sustainable growth is good, but halting it can quickly lead to a downslide and the end of the business.

Addressing the issue

I had to evaluate my options. I had exhausted every possible marketing channel, and the target audience was too small. Trying to level up marketing was not a good idea. I needed to appeal to another audience.

I started to work on building integrations with different accounting software. Although the number of users of these software was smaller, they were also less price sensitive, as these were much more expensive solutions. So, I had to reverse-engineer another set of databases, build the integrations, and explore ways to get into the new audience.

The work then I did paid off in an unexpected way later.

Acquisition?

Three months into the plateau, my phone rang. My competitor was calling. We had been in touch since the start, talking a little about potential collaboration (that I did not want as I preferred to make every business decision by myself) or acquisition (which I preferred) at least once a year. Previously, the price tag they suggested was always an order of magnitude less than what I have valued my business at. This time, they asked me to calculate a fair value, believing we could agree. When I had put down the phone, I was happy for a minute about the opportunity, but then I realized that I needed to be highly vigilant about every step, as every tiny mistake could reduce the last price by tens of thousands of euros. I needed a plan.

The plan

I started by reading up on business valuations. Unfortunately, I found hardly anything relevant to the size and type of my business. My software was more like a plugin with significant risks. There was always the concern that a slight change in the tax regulations or the closing of the import feature in the accounting software could instantly decimate the whole operation.

However, I was confident I had at least three more years at the actual revenue level, given that my backup plan worked and there wouldn’t be any black swan events. So, my baseline was three times my annual profit.

First and foremost, I followed the advice I read in Built to Sell, wrote down the last price I would be satisfied with, and put it in an envelope.

I knew that even though we would be negotiating about the price a great deal, the first number I present will act as an anchor. I was highly confident I wouldn’t get more than that.

Understanding My Competitor’s Perspective

So, I had my range, but what about my negotiation partners’?

They would acquire my business mainly to eliminate the possibility that I would one day overtake them in our segment. I anticipated they would want to see a return on their investment in a few years. I ran my business at a low cost, so my profit rate was high. They had a lot of employees and a more mature company structure. I knew that the way we look at the business would be different.

Different ways of calculating the business value

I opened the negotiation with a price slightly higher than I calculated, as I understood that whatever I said would define the top of the range. After signing a Non-disclosure agreement, I presented some metrics about my company for the last year. These included the MAU, the monthly new sign-ups, and the cancellations. For a while, we couldn’t agree on the business value. Then, I asked my competitor to show our cards and tell each other what method we used to create our numbers.

It turned out that they used the churn rate to calculate my users’ lifetimes and multiplied it by the number of users and the monthly subscription fee. Thanks to the months when they changed their pricing, my churn was relatively high. They had no intention of growing the number of users of the product but instead diverted them to their own, so applying multiples was out of the question. Although it was above the number I had put in my envelope, but only by a little, so I refrained from accepting it.

After some clarification and calculations on the additional business values, like the users of simpler products, an unreleased integration with another software (remember my plateau mitigating strategy?), and the potentially necessary development work, they made an offer I happily accepted.

It was a rollercoaster, and part of me just wanted to get it over with, while the other part urged me to slow things down. Being patient and keeping the conversation going helped us see each other’s perspective.

Finalizing the contract

From that point, things were still to discuss, such as the vested amounts during the handover period. I thought it would be easy since we both wanted to finish the process immediately. I had read about the other’s experiences and how this could take additional months.

I thought: not me, not us, we can do it in a week. It took another two months to get to the final version of the contracts, thinking about everything that could go sideways. Our lawyers couldn’t agree. We couldn’t agree. We had other work to do.

I mentioned the rollercoaster before, but this time, it got intense as days passed while I contemplated backing off the whole thing altogether. Almost half a year passed, while my main focus was negotiating the deal and not growing the business.

I communicated my frustration and transparency helped us overcome an impediment once again.

Closure

Even though I always considered the possibility of selling the business, it was hard when it finally happened. The silence was deafening after I handed over every account and got locked out of the customer service emails. My mind kept wondering about potential ways to grow the business and improve the product, and I constantly needed to remind myself that it was no longer my concern and that I was free to do whatever I wanted to.

During my accidental entrepreneur journey, I learned much about pricing models, marketing, sales, and software development difficulties. I got to talk with my customers every day, which helped me enhance my empathy. I learned the true meaning of self-motivation when no one else urged me to work. I learned a lot about myself.

I am sharing my journey and giving you a glimpse of what it means to create a software business. With this, I conclude my articles about this period of my life. Now, I have my closure.

Challenges and Initial Efforts

One of the first challenges was the small, particular target audience. Bans and deletions often block marketing attempts in Facebook groups and forums. Even the accounting software’s newsletter was off-limits due to existing competitor partnerships. So, I focused on areas within my control: SEO, PPC, and word-of-mouth.

SEO Success

Due to the limited competition, SEO was relatively straightforward. By optimizing technical SEO and targeting relevant keywords, I secured top positions for critical functions of my software. Additionally, I ranked highly for the name of the accounting software, which significantly boosted visibility.

PPC Campaigns

Initially, PPC was a struggle. I hired contractors who didn’t deliver the desired results, so I dismissed them and took a Udemy course to learn Google Ads myself. By fine-tuning the settings, Google Ads became my second-best acquisition channel with a €10 CPA, while my monthly fee was €57: criminally cheap. For Facebook ads, I hired creative professionals while managing the technical settings myself, ensuring the ads resonated with my target audience - mainly women over 50. I was sick and tired of showcasing young professionals in suits, smiling at their Apple MacBooks, showing charts, and suggesting they were accountants. I wanted my illustrations to reflect how the target audience looked while working or doing things they would love to do instead of work, like spending time with their loved ones. This proved to be a good choice, resulting in high click-through rates.

Hijacking the customer service

One amusing incident involved advertising on Google using the name of the accounting software. One of my ads included my customer service phone number, leading to calls from people seeking help with the accounting software. My customer service team, well-versed in common issues with the accounting software, was able to assist these callers. During these interactions, they also pitched my software, guiding many through the registration process during that initial, mistaken call. This mix-up turned into a surprisingly effective acquisition channel!

Word-of-Mouth Marketing

Word-of-mouth played a crucial role in our growth. I set up automated emails and personally requested referrals when providing extra services like programming and data cleaning at no charge. This personal touch encouraged satisfied customers to spread the word about my software.

Results and Impact

Thanks to these different avenues, my acquisition funnel had a steady stream of new users every month. The experience taught me the importance of continuous learning and a willingness to adapt, essential to successful marketing in a niche software business.

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.

How I Stopped Worrying and Learned to Love Go

The first and most challenging problem was the decision on the code’s programming language.

I made my initial prototypes in Go to quickly produce a simple executable without installing additional frameworks like .NET. My experience with these automatically updating frameworks was that they introduced a severe vendor risk, as they could break the application anytime without warning.

I could have written it in C++, but I wanted to focus more on the algorithms and use pre-existing solutions for simple tasks. I could also have used Python with PyInstaller to bundle an executable, but it seemed like I was about to use it for a job it was not designed for.

My customers mostly used old, low-tier laptops in their work, and my software had to run a complex algorithm in minutes, so it was great to use Go’s multithreading capabilities. Once in a while, someone called me to say that the software was running endlessly without a result, and after inspecting their datasets, I was always able to improve the program so it would finish its job in an acceptable time. So, using Node.js and Chromium to build the software was entirely out of the picture.

After creating and validating the prototype with potential customers, I wanted to make a proper desktop application with a graphical user interface. I looked up potential libraries and even contemplated switching the programming language again. My main concern was still the vendor risk; I imagined the day when a Windows Update would knock out my software and all my customers would start to bombard me at the same time while I franticly tried to triangulate what they had changed before they had written “minor fixes and performance improvements” in their changelog. Sounds familiar? Sorry for the unexpected flashbacks.

That’s how I ended up sticking with Go and using the GTK toolkit. It allowed me to quickly assemble a usable user interface, although it was a bit ugly. In fact, that was the central theme I heard back from customers later on: “It’s not pretty, but I could understand and use it in seconds.”

Go Big or Go Home

To run the business, I needed systems to handle registrations, activations, license renewals, automatic emails, and a whole set of other small things. I didn’t want to rely on other parties if it wasn’t strictly necessary, nor pay money for services I could implement in a day or two. I know what you’re thinking: this is what most software engineers say; they tend to underestimate the complexity of every problem. I could have used pre-existing solutions, but I wanted to quickly change things while the day-to-day operations formed based on my early experience. Most mature solutions were loaded with features I didn’t want to use, at least not in the first few months. I was very cautious in using the time I dedicated to growing the business, but I also wanted to have fun.

I decided to code everything else in Go, too. It was easier for me to remain in the same language and, hence, mindset while switching between the maintenance of the application and the complementary services. I anticipated finding a developer with only one language criterion would be easier when I decided to hire someone or sell the business.

It was evident that hosting these services was not a good idea; I used a cloud service provider instead. I wanted to focus on building the business and not restarting and updating servers, so I implemented what was necessary with serverless solutions on AWS, mainly utilizing Lambda workers.

The few areas for which I used an external solution:

• Invoicing: it’s highly regulated, and there were stable, cheap solutions available

• Transactional emails and newsletters: I estimated that I would remain in the free tier for a long time and wouldn’t have to worry about SPAM management

• Website analytics: I used Google Analytics with a custom Tag Manager magic as I had previous experience with them.

Push and Pray: My Battle with CI/CD

My main concern was ensuring that I could deliver updates quickly. For the “additional systems,” I was satisfied deploying new versions from my computer through AWS CLI commands. There were just a handful of them, and as they were organized as microservices for small tasks, I rarely touched them after the first versions.

The desktop application was trickier. I implemented a self-updating mechanism into the software because I knew I couldn’t rely on the customer to update it manually, especially when I released new versions daily.

I needed to compile the code, bundle it into an installer, pack it in a different format for the automatic updates, sign it, and upload all of these to S3. At first, I did all of these from my local environment. Still, after I got into some trouble because the unfinished parts were getting into production, I decided to automate all steps in a CI pipeline on Gitlab.

It took countless hours to get it right, mainly because of the technological decisions I made earlier. I had to assemble the software on a Windows machine - as I realized after a depressing day spent with different Linux images - and it wasn’t easy to install everything before I could start the primary process. I had to make several workarounds in the building process; for example, I had to duplicate the package installation line, as the dependency tree resolution always messed up the first time, but got it right the second time. Specifining exact versions, or any clean solution didn’t work, just this ugly hack. And I still needed to fix a config file with a fine-looking sed command. The fact that I had to kill random tasks that might not stop after the compilation was done was just a minor inconvenience after all of this.

The pipeline became complete after I had set up a “staging” deployment to upload the new installer to a different location. The whole thing looked unstable. Every time I ran it, I feared it would break somewhere, and I would have to start the detective work again. Fortunately, it happened far less than I expected and not once when I was in a hurry. Looking back, it would have been better to create a custom Docker image, which I could have used to run the building process. It seemed to be much more effort at the time, but now I know the time invested would have been worth it.

Conclusions

If I had to start again knowing what I know now, I would most certainly go the same way I did. Go is a great language to work with, and new, more stable contenders for UI frameworks have emerged over time.

Having had more experience with .NET, I might have used WPF, even though I would have to prepare for the customers’ inevitable “it worked yesterday” calls. In return, I would have received a more mature framework with better documentation. In this case, I would use Python for the microservices, as finding someone to manage them is easier.

I think the best language and framework for anyone is the one they truly enjoy working with. The most important thing is to know its risks and limitations to ensure healthy product development.

My software in a nutshell

To set the stage, here’s what to know about my software: it was a plugin for a specific accounting software. It wasn’t too complex but solved a severe problem, eliminating countless hours of mundane but error-prone work.

It took the transaction details from the clients’ banks, looked up the invoices in the accounting software, matched them, and prepared a file that the accountant could import. Piece of cake.

Value for money

Most accountants calculate their fees by adding a constant amount for mandatory tasks and a variable amount based on the quantity of the invoices and bank transactions the clients produce. It was not an overstatement to say that this solution could disrupt the whole SMB accountant business segment by reducing this variable, manual work; even sole proprietors could take multiple more prominent clients, like webshops that were booming in 2020.

The landscape

Disclaimer: The business was in Hungary, but I converted the prices to EUR for easier understanding.

I knew my potential customers had anchors for the price they would pay for such software, so I analyzed my market research in detail.

The accounting software (let’s call it TAS from now on) was dirt cheap compared to its competitors. Its creators charged a one-time €200 fee and a €40 per year maintenance fee, and they dominated the Hungarian SMB accounting space. However, they were always busy keeping up with regulatory changes, so this opportunity to create additional value remained open.

Existing competitors - business models to beat

By the time I entered the market, there were three main participants. Their solutions were entirely different:

• Competitor A had multiple Excel sheets with VBAscripts.

• Competitor B offered a complete ERP solution that could work with TAS.

• Competitor C, who built a SaaS connecting with more than ten different accounting software, had the most significant market share.

They all charged a monthly fee based on the number of banks or clients they supported or the number of transactions they processed, with a minimum threshold. Moreover, Competitor C even charged a one-time registration and onboarding fee, additional sums for more users, and different email or phone-based customer service tiers. So, depending on the solution chosen, an average customer would pay from €25 to €250 per month, with an additional €200 upfront cost. In reality, only the last, most expensive competitor’s product was usable.

Safe to say, the market was not at rest with a standard business model but rather in its storming phase. Spending 10-to-100 times more than the base product monthly on a plugin seemed crazy.

My evaluation

Deciding on the basics

Since the accounting software was a desktop application, I also decided to develop a desktop application. This also saved me from cloud costs and the need to create a robust but cost-efficient architecture.

I wanted to build a subscription-based business because the software needed constant updates and used various inputs from different providers, which changed almost daily.

I had a few additional primary drivers in mind when I thought about my approach.

• I wanted to charge a fair price, which justifies the work I put into this endeavor at nights and weekends while I keep my regular job.

• I wanted to build a service I would gladly use as an accountant.

• I wanted the business to be as simple as possible.

Inviting them through the door

Free trial

The first thing I decided was that I wouldn’t charge a registration fee. Instead, I offered a 30-day unlimited trial that I extended if the customer couldn’t make the time to test out the software. I didn’t require a credit card upfront; I just needed a registration with billing details and a phone number.

Free, personalized onboarding

We scheduled a one-hour free onboarding call within hours after registration. Some companies automate their onboarding with videos and popups in the software. Some use a prepared dataset to show the main features. I took a hybrid approach: I recorded a video that went through all the main features and placed it on the landing page. In the registration confirmation email, I urged the customers to watch it again and pick one of their clients to test the software with. My customer representative held the onboarding on the customer’s computer with screen sharing. With their help, customers could process their first datasets and load them into their accounting system. We could ensure the customer had their “aha moment” within hours after registration, and we built a genuine connection.

Unlimited customer service

Limiting how customers could reach them was a bad practice at our main competitor, in my opinion. If a problem appears, it mostly happens when the client is in a hurry. So, I wanted to avoid creating tiers for whether they could get us by phone or email. To go one step further, knowing the customer base, which consisted mainly of 50+ year-old women with modest computer knowledge, the primary line of communication was the phone.

Results

These could all seem counterintuitive: spending this much effort on a non-paying customer and letting them nag us over the phone. However, the results were even better than anticipated: we had a 70% trial-to-paid conversion rate for the first year, and the customer representative never worked more than 20 hours weekly. Most of that 30% didn’t go through the onboarding, tried the software themselves, then left or haven’t even installed it. So, onboarding was the critical success factor.

On the matter of fees

Quantifying the added value

I considered all the possibilities for calculating the monthly service fee.

As mentioned above, the accountants used the number of transactions handled as a metric to calculate and justify their costs. So, if the client’s business grows, they can charge more, right? So, I can incorporate expansion revenue in my business, too, right?

The sad truth is that most clients view accounting as a necessary evil and wouldn’t want to pay more for the “same service.” They would even argue to spend less after they learn that their accountant reduced the work hours needed by half or more. One other side-effect I envisioned is that customers would optimize their usage, only using their quota for the more complex data, and eventually cancel the subscription when that complex client leaves. I wanted them to get hooked and use the software for all their clients, even the smallest ones. I wanted resiliency.

To tier or not to tier?

The last thing to contemplate was whether to have tiers at all. Should a sole proprietor really be expected to pay the same as a firm with five accountants? Or should I base it on the number of clients? Nothing seemed right; it was tough to draw a line.

Instead, I changed my perspective. I decided to charge a €57 monthly flat fee that was low enough that a single accountant could afford it but high enough that it advertised its intrinsic value. It was much cheaper than the most significant competitor’s price, and it served me well: together with the free trial period, it was easier to convince people to at least try out my solution. I decided to monitor my customer base and introduce tiers only when it would make sense.

Conclusion

Examining existing solutions, I realized that I am only against one heavily overpriced competitor, most certainly because of their high maintenance costs and, of course, their monopolistic position.

I entered the race with a more reasonable price, a customer-centric mindset, and a better software solution. Of these three differentiators, I considered the lower monthly fee less important in my early success. Instead, I worked tirelessly on creating a better user experience. But was I right, eventually?

I will write about it in my post, Building With the Exit In Mind, telling you how I realized it’s time to sell.

But how has it started? Did I have a well-defined plan? Have I conducted thorough research before selecting a market to address and a problem to tackle?

The short answer is: No.

I am an accidental entrepreneur.

I graduated as a Software Engineer but never worked as one. I worked as an IT Project Manager and later as a Product Owner because I have always been more interested in coming up with ideas, talking to customers, and making hard decisions. However, I enjoyed coding and worked on hobby projects frequently.

The idea for the software I later sold found me, and I did not go after it. My parents have an accounting firm. One day, my father asked me:

‘Could you create a small software that transforms this XML file containing invoice data to the format of our accounting software?’

‘Well, Dad, it sounds easy; what’s the catch?’

‘Nothing really; there are only a few rules to map the values.’

So, to make things enjoyable for me (and for other reasons that I will discuss in the Technical Difficulties), I installed Go on my computer and wrote my first lines of code in this superb language. Then, on a cloudy weekend, I created the XML converter, which runs on the command line.

‘Hey, Dad, I have finished the program!’

‘Thanks! I might need another just like that...’

‘Ok...’

‘Just a bit more complex...’

‘Sure...’

‘I have already tried two solutions. The first one was in an Excel sheet, screaming random VBScript errors every time I tried it. The second one works, but they charge so much that we would be better off hiring some trainees to do it manually. Both are missing key steps and need much manual work.’

‘So you say I should try it even though others failed?’

‘Oh, I’m sure you can do it. All you need to do is match bank transactions with invoices and load them into the accounting software.’

‘I guess the transaction comments often identify the invoices...’

‘They sometimes leave them out. Oh, and sometimes the payer is different from who got billed.’

‘...’

‘...and they can settle multiple invoices in one go. Or pay with a credit card. And, of course, there are the package couriers...’

‘Do you think I can come up with a better algorithm?’

‘There might be some more edge cases... [There were many - Tamás] I think you can get it done quickly [It took two months - Tamás].’

When I had finished my initial solution, it looked like this: you had to edit an XLSX file (the configuration) to point to the accounting software, set up manual rules, select your input files, and drop them on an EXE, hope for the best as a command line window showed how the program franticly works its way through them and generates an importable file.

I held a small demo for my parents, showing how it handled all the edge cases. They were amazed. The UX was terrible, but I reduced a week’s work to an hour. My mother told me I should sell it to accountants; they would pay good money. I jokingly told her that’s what every programmer’s mother says to their child.

But I wasn’t an average software engineer working on a one-off program. I was a product person who was spending time not only coding but also doing market research. I reverse-engineered the competitors’ solutions, studied their business models and marketing channels, and collected industry surveys and statistics.

I knew it was a sellable asset, not because ‘my mom said so,’ but because I recognized the underserved niche market and had already proven that the core of the business could not be built quickly.

All I needed to do was to add a GUI layer. And set up a landing page. And create a system for registration, license management, and payments... And I still needed to come up with a business model.

Ok, so there was a lot more to do, and as I was only working on it nights and weekends, it took almost a year. Finally, on the days when the world went into its first global lockdown during the COVID-19 pandemic, I was ready to launch my product to the public in one of the worst possible times. After a year, I had almost 100 customers. Another year later, more than 200. I signed a deal to sell the product to my main competitor the following year.

In the meantime, there were many decisions to make and areas to explore. I will write about them in separate articles, so feel free to follow me as I share my experiences of becoming a solopreneur.