Application Context constantly being destroyed and reloaded

This post should help those who face the situation where their Application Context constantly being destroyed and then reloaded. The issue also might follow with these log messages:
- INFO: Additional JARs have been added : 'someJar.jar'
- org.apache.catalina.loader.WebappClassLoader modified

I know this issue has been address over the web, but if I would be able to save even one developer few hours then it is worth the time I spend writing it.

To make a long story short - this issue is caused due to a corrupted jar being deployed in your application.
The INFO message indicates which jar caused the problem exactly.

Please notice that sometimes, modifying the jar in the application might not be enough. One might need to seek and destroy the corrupted jar in the deployed application.

Some solutions on the web discussing seeking the jar in Maven (like here), but in my case it was a simple copy & paste into the project WEB-INF/lib folder.

If you use Eclipse (STS) and Tomcat and the server is configured to "use workspace metadata (do not modify Tomcat installation)"  , then going into the Tomcat webapp folder will not help
You can find the mentioned jar by right click on the Tomcat instance (in the Server tab) and choose open.
Then click on "open launch configuration". In the VM arguments inner window, you will find the full path in the variable:  -Dwtp.deploy .

Please stop defaulting your startup with freemium

Recently it seems that the Freemium model is dominating almost every SaaS startup.

I guess that the motivation for this model, from the startup point of view, is to try to solicit as many customers as possible to use the product (Hey, its free!) and then they assume that after the customer have used the basic stuff, it will be easy to convert them to more advanced paid version.

But is it really what the customer needs? Is this model ideal for paying customers?

Please read on.

What's wrong with freemium ?
For the selling companies there are evidences that the conversion rate to actual paid user is very low (~3%).
So the problem is double - not only the company which offer the service has low paying customers, but it also has tons of unpaid customers, which cause them overhead for nothing.
Moreover, for very heavy usage (for paying customers) the selling company also looses for extensive use of resources, since the plans are often for the amount of features used and not the frequency.

For the customer, this model is also problematic, since usually freemium:

• Bundles plan with features - So free users don't actually have access to the full set of features. This might cause them not to use the product in the first place.
• Bundles plan with amount of use - So customers who need the advanced mode, but have low traffic, are in a problem.

So the question is why binding the product possible set of features to the traffic amount?


Pay per usage (as you go)

Pay as you go

I think the customer will be much happier if he will be exposed to the complete feature set. It will help him evaluate the product better, examine the added value and potential fit.
The differentiation between customers should be the amount of usage (e.g. Amazon cloud pricing)-
Paying very few is almost like a free product, so it will not set any high entry bar. If any, it will push away one with no real interest and leave in only those who really need it (and might be willing to pay more in the future).

Moreover, paying per usage will be fair for the customer, assuming, that if his usage volume increases he benefit more and could afford to pay more.
It will also be a better approach for customers who have seasonal demand for their product, so they pay exactly as their business consume.


Pay per usage with a twist
Naturally one can improve this model by fine tune it for certain needs:
- Support aggressive/Freemium like marketing: Declare no charge policy until the cost will be aggregated to certain minimum threshold  (e.g. 5$). This will offer many potential customers room for experiment, with the difference that there is no migration needed for paying mode. It's already on.
- Support suspicious & skeptical customers by providing billing limitation (e.g. Block activity once billing account will reach 10$)
- Support enterprise customers by providing major transaction discount on large usage volume or maximum payment.

Successful use cases for the mentioned model

 A good use-case for successful pay per usage model with fine adjustment is the city bike rental program like http://www.velov.grandlyon.com/. -  users first need to pay a low rate subscription fee (so payment means are already in the system), then users would pay per usage time. The adjustment in this case is that there is no payment for the first 30 minutes. This is done since the company/city want to support short distance rides.
So this is a good example how to provide a free use but with a protection for the business against over use and with minimum income guaranteed (the subscription).


Use case where freemium model is bad
kampyle is an online feedback tool with sophisticated data analysis. Their free plan has almost no significant features, and is limited to very low feedbacks number. The downside is that free users will not be exposed to the advanced features which make this product great. Moreover, in order to enjoy the advance reporting users must buy the Silver plan (249$), even if they have no significant traffic. Why bind features to traffic ?
Other excellent products who these bindings approach are UserVoice (feedback tool) and SurveyMonkey (online Survey services).


Use case where freemium model done right
A good use case where freemium model is done right is Animoto.
I don't have any conversion rate number (from freemium to paying) expect the fact that they are quite successful, so I guess it is more then average.
The difference in this case is that the nature of the product usage (e.g. for special events, once in a while..) make it a must to buy one of the plans. No one would like to produce his child birthday movie (i.e. a rare occasion with high sentimental value) with resolution he can't utilize in wide screen TV to present the party guests.
In that case, providing a taste of the product, just for the customer to see if this is the right choice is correct.
Users are unlikely to use that product on a daily basis, therefore no fear for abuse.

*****************
So my wish is - please - be creative!
Think carefully what your clients truly need and how to address them in a win-win way.
Think how your product is being used and target for it!

Please don't use the Freemium approach as default.