To blog |

How much should our product cost?

December 13, 2011 by Vladimir Šor Filed under: Plumbr

Until now we’ve been focusing on developing the software – we believe that a company without a superb solution is worth nothing. However, as we also have mortgages to pay, there rose the question of our product’s revenue stream. And hence the problem – what would be the revenue model of Plumbr and how much should it cost?

Any product’s price should reflect its perceived value and be competitive. Plumbr is no different here, and its price should be related to the severity of problems it solves or helps avoid. Let’s discuss the value of the product and possible licensing models in more detail, so that we could ask in the end – how much should we charge for our product?

The value of Plumbr

We asked a fellow marketroid to phrase their opinion on what the value of Plumbr is. And we like the result:

First of all, Plumbr allows your customers to eliminate their Java apps’ availability problems caused by memory leaks. By having Plumbr report problems well before these affect production application, your customer avoids negative business impact caused by a slow or non responsive application. Secondly, Plumbr helps minimize the time it takes to solve a Java OutOfMemory problem. Your customer wins from not wasting their top developers’ and Ops’ time on hunting down and solving the leak, and on holding the production app’s hand during the whole process.

For us, it seems that the latter is actually easier to put in numbers. An OutOfMemoryError always catches you unprepared. Since we have to generalize, we’d estimate that a memory leak in a decently sized enterprise application with moderate rules for security etc (see our Solving OutOfMemoryError blog post series for reference) takes around 3 man weeks to solve. This includes the Op’s and developer’s collective time for hunting and solving the leak, some QA time for regression testing, and some management time for communication and release coordination. Of course, the actual costs vary in a very large scale, but this is what we currently can estimate based upon our team prior experience.

Let’s say, in a decently sized environment (with some 10-50 people developing and managing the application) OutOfMemoryErrors occur on average twice a year. Above-the-average guys who get to solve the leaks probably represents around $10k of costs per month (again, as good estimation as any other, this number is taken from Fred Vilson’s recent blog post. With these estimations we come to the conclusion that avoiding the memory leaks is worth $15k per year (two times the three week troubleshooting sessions within a year for a guy with the cost base of $10,000 a month).

Now, we should add to that the loss of revenue (profit) that any SLA problem bears. Until you solve the leak, restarting the JVM is inevitable, and this often means loss of sessions and/or service downtime. However, the differences among different businesses in this regard are far too big for us to dare to generalize. If the customer directly earns money with the Java application (eg. runs a web shop) then the losses might be huge. If the application is in a business supporting role (eg. a corporate web), the losses are probably smaller. But they still exist.

Competition

We also tried to compare ourselves with the alternatives on the market, but immediately ran into problems. First of all, differentiation-wise, there are no alternatives available that would both 1) monitor for memory leaks in real time and proactively report when something fishy is found, and 2) minimize the time it takes to solve the leak by reporting which objects leak, and the line in the source code where the leak originates from.

We have a bunch of less direct competitors though, and can divide them into three categories:

We have separate blog posts coming up where we compare Plumbr in all those categories. What is common to all of them, is that they need more expertise to use (which takes time and money to grow or buy) and they require more time for analyzing the reports to uncover the source of the leak.

After uncovering these excuses we decided to omit competitor pricing analysis from our revenue model calculations. But maybe we are heading to the wrong direction here?

Licensing model

As seems to be a rule nowadays, we also believe that the most effective way to bill for Plumbr would be using a renewable periodic license. We are thinking of billing on a yearly or 6 months’ basis, per JVM. The license holder would receive all upgrades during the license validity period without additional cost.

Another possible source of revenue might be charging for every leak report generated using Plumbr evaluation license. This function is being offered for free at the moment, and we don’t see it as the main source of revenue (but feel free to convince us in the opposite).

Also, the value of Plumbr is very different in pre-production and production environments. Since Plumbr is able to warn of the approaching problems and makes it possible to avert them entirely, it is most effectively used in production. Of course, we shouldn’t forbid using it in pre-production environments as well, but since it’s usually very hard to uncover memory leaks in environments with artificial application usage, we’d price such usage cheaper than running Plumbr in production.

One more thing – we want to support the academic community, and offer Plumbr for free to them. The reason being that we still vividly remember how good it felt to workhack with bleeding edge technology as a student, and how big a barrier was even a small price tag on any software package. But take this a side note, that should not divert you from the general topic of how much Plumbr is worth.

We are asking for your help!

The aim of this blog post is to ask your input on our thoughts. Tell us your opinion:

  1. How do you perceive Plumbr’s value, does it align with the quote from the marketroid above or would you add or remove something?
  2. What would be the justified price of Plumbr per JVM for a yearly subscription for:
    • Pre-production use
    • Production use
  3. Are we on the right track with the pricensing model in general? Would it match your expectations?

Leave your thoughts in the comment box below. We thank in advance for your contribution!

ADD COMMENT

Comments

Could we see educational discounts for students with a .edu account?

Steve

Sure. To be honest that is what we’ve been offering already. Do you have a specific project in mind? Just send a short description of what you’re thinking to do with Plumbr to support@plumbr.eu and we’ll figure something out!

Priit Potter

There’s no way I would subscribe to development tool software. It should be lifetime licencing per JVM version. I see this as a development / preproduction tool; it’s not something I would advocate to my clients to put on live servers. Anything which is not supported by the platform vendor will just detract from any calls for support from said vendor regardless of the fault. nnThe target for this software should be vendors of JVM-based solutions. It isn’t really needed to be run on production servers in my opinion.

Antony Hutchison

Very interesting ideas!nnThe problem with memory leak hunting is that for the leaking objects to stand out from the rest you need to 1) have the “right” usage, ie. usage that executes the leaking code, and 2) have the application run long enough. In development you normally have very little usage, and in pre-production the app is sometimes restarted too often.nnIf you know that you have a leak, you can take special care to eliminate these barriers, but if you want to catch accidental leaks, it is difficult to get enough certainty from devel/pre-production. That is why users actually want/need to use the tool in production and why we strongly consider offering it.nnYour point about conflict with vendor interests is very valid though, thanks for raising it!

Priit Potter

I had good results with JMeter and Apache Bench for hunting leaks. Obviously it’s not feasible to run these on live sites. The only case that long running really helps with is date/time related issues; like when batch processing occurs or log files are rotated.nnIt looks to me like you are pitching your product at developers / devops when maybe the target market is department heads and QA teams – people who want to be reassured that it’s operating normally and that there will be no surprises, and people who find faults pro-actively. It creates evidence to attach to the bug tracker ticket – unless there is an automatic feedback mechanism such as email. Log files can easily get ignored.

Antony Hutchison

Hi,nI think you are on a good track. There is no free tool for that, because it is far from being trivial. While CA APM and AppDynamics have some overlapping features, I would recommend not to compete with APM tools.nYour target audience is the DevOps guy wanting to learn about leaks using the production system. So I guess a floating per JVM subscription license would be best for that. I would make different prices for different environments, as it makes the whole thing more complicated.nnIf you would go below 1000 per period per jvm, that would be an aggressive price, which would ease buying as it bypasses many approvals. At such a price, I could imagine a few of our customers who would buy a handful of licenses.nnFabian

Fabian Lange

Unfortunately, I guess you do not consider Open Source projects as a target for your product, since you may not seem to offer a license suitable for them.nIt is a shame!.

Carlos Hoces

@Carlos: relax… that’s why they are asking this audience for comments.

Aleksandar Vidakovic

Three months to reply? I hope Carlos has calmed down by now.

Antony Hutchison

Open Source is not the same as non-commercial. As I see it, this product is designed to be used on live production servers and not during development cycles (there are far better tool sets for examining development-grade, unoptimised byte code), and any organisation deploying this is most likely to have a substantial budget allocated. In the case of not-for-profit organisations, I dare say a plea to the sales team would likely yield a discount or a free licence if they have any heart.

Antony Hutchison

Thanks Antony, we couldn’t have said it better. nnOf course we support open source / not-for-profit projects. We are also testing Plumbr with different open source projects ourselves, and when we discovered leaks we submitted reports/patches to the authors.nnIf you have a leak in an OS project, just get in touch with us and we’ll get it sorted out!

Priit Potter