I've Finally Figured Out Unit Economics!

"I've finally figured out unit economics!", I exclaimed today to myself. Don't rush to close the article if you, too, know what they are because what I have figured out concerns specifically MY OWN project and I hope what I have to say here will help others too. Thanks to a pal of mine, Kolya, who dropped by our office today to have a chat and incidentally prompted these ideas to me.

So, when speaking about unit economics, people will usually ask the following question: "How much does it cost you to acquire one customer?" I couldn't answer it for several years and felt pretty embarrassed because of that. Our team has gradually grown up to 12 persons but for some reason I still have had no answer to this simple and important question.

Evgeniy Ryzhkov, PVS-Studio

To understand why I couldn't answer it (and how, despite that, our team managed to grow up to 12 persons), one needs to understand what kind of job we do. Our team develops a software tool for programmers - static code analyzer PVS-Studio. It is designed to parse software's source code and warn the programmer about any potential issues found in it. What makes this tool valuable is that it enables bug fixing at the coding stage (when it is very cheap) instead of the testing stage or, even worse, when the product has already shipped to a million users. Our product is a costly one: the minimal annual license for a team of up to 9 developers costs over €5000. License renewal costs 80% of the original price. To promote our product, we thought up a special format for our articles. We analyze well-known open-source projects like Chromium, Unreal Engine, Doom, etc. and write articles where we discuss the bugs we have found in their source code. There are always bugs to be found in any project, so it's OK. We do not advertise our tool straightforwardly; we just find bugs and tell the readers that it was PVS-Studio that helped us do that, so if they want, they can check their own projects and maybe find something interesting too. This approach works great because programmers (our users) don't trust advertisements and what we do is no advertisement. So people will download the trial version, check their project, find some issues, and rush to their manager pleading them to purchase our tool. It usually takes 1-3 months (a sales cycle).

PVS-Studio's logo

Now, what are our unit economics? Unknown! How much does one customer cost? Uncertain! We can, of course, calculate the expenses on writing an article, publishing it, attracting the audience, and so on... And we do that and know that one article costs us about 3-5 person-months of a qualified programmer's work. But it doesn't answer the question: "How much does it cost you to get a customer?"

However, after Kolya's visit today, my colleague and I started discussing it for the umpteenth time. And it finally struck us that the question had been wrong from the start! It actually should have sounded like this: "Look guys, this field you're working in - is it profit- or loss-making?" It is this question we need to know an answer to. It's not always possible though, so sometimes people paraphrase it as: "How much does it cost to acquire one customer?" or "How much profit does one customer bring you?" OK, let's sort it all out by examples of our business.

So, our main area is development of the PVS-Studio code analyzer. Is it profit-making or loss-making? How do we answer this question? Well, it's easy. Take the profit for the last year; take the loss for the last year. If we are satisfied with the difference between the two, then we are making profit. We do not need to know how much attracting one PVS-Studio customer costs us if we do this by means of our articles. We just need to know that our job is profitable in general and that we do it right.

Another example. PVS-Studio ships both with a more popular version for the Microsoft Visual Studio IDE and a less popular version for the Embarcadero RAD Studio IDE. The number of users contacting our support service regarding Embarcadero RAD Studio is almost zero. This version hardly sells at all; the expenses on its development and maintenance outweigh the profit. Because of that, supporting Embarcadero RAD Studio in our tool is not profitable, so we have dropped it recently. That is, we have unknowingly measured those very unit economics for our business.

One more example. We have a lightweight version of our major product, known as CppCat. It has a different pricing and licensing policy: a personal CppCat license costs $250 (compare it to €5000 for PVS-Studio). We have calculated the profit earned by the product during the last year and the expenses on its development and maintenance. We didn't like the difference and decided to close it down soon. We failed to hit our unit economics this time. Why don't we kill this project right away? Because this process costs money as it involves site redesign, sending emails to users, attending to current customers' questions, and other stuff. But we will surely finish it as soon as possible.

CppCat's logo

OK, now we've figured it out for goods. What about services? Can we manage to measure the unit economics in this area? Some time ago, we started providing consulting services to our clients. Roughly speaking, it deals with highly customized software development. We calculated the contract price and the loss based on the results of a half-year term of work. The balance was positive. So?.. We had hit our unit economics, so we kept working. We extended the contract for one more year and just do measures at certain intervals. It's those very unit economics. But some contracts have to be cancelled, for they don't prove profitable.

The last example. It has occurred to us recently to start selling an additional service - implementation of custom diagnostic rules for our analyzer. These diagnostics deal with detecting very specific bugs relevant for a particular project or company. We did a rough estimate of how much it would cost us to implement one rule and got some figures. We saw that it was too low for one rule and arranged it so that a user could only order a bundle of three rules at least. This way, we do like the profit we are going to make. So we can sell it on. Again, the unit economics have been met.

So why does everyone keep asking, especially to recently launched teams, the question "How much does it cost to acquire one customer?" and "How much profit does one customer bring?"? Well, they just don't have a history; they don't have clear marketing. As for us, we have both clear marketing (we know how to attract users) and the profit/loss history for the last year. That's why we are interested in maintaining control over "is your field profit-making?" rather than "how much does one customer cost/bring?"

But if a team is only 3 months old and producing something, even if they have 10 sales already, well, then it's the only question to ask them.