200 leaks sounds cool, but how does it translate to money? You cannot force a leak to go away by just throwing piles of cash towards it. Instead of spending cash you spend time. A lot of time -  a memory leak in a decently sized enterprise application takes around three man weeks to solve. This includes the operations' and developers' 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 the initial customer feedback.

Three man-weeks might not sound awfully lot, but translate this into cash and things start to look a bit more sour.  Quoting Fred Vilson - “ A good rule of thumb is multiply the number of people on the team by $10k to get the monthly burn”. Ouch. This three weeks now looks more like a $7,500.

If we now apply some hardcore math and multiply the 200 (number of leaks found by Plumbr) by $7,500 (average cost to solve a leak) we can confidently say we have saved at least $1,500,000 to our early customers. This looked impressive, and as we didn't have any major bugs open either, we decided to step ahead and call ourselves production quality alias 1.0.

Along the lines we also worked out the initial pricing model. The use of Plumbr is still free and we do not expect you to pay a dime before we have proven our value. You are only asked to pay when Plumbr detects a leak in your application. Plumbr notifies you of the existence of the memory leak, but to find out what is leaking and how to fix it, we ask you to fill in the credit card details (you can do this only once if you buy a subscription).