-
Notifications
You must be signed in to change notification settings - Fork 91
Description
Introduction
Tomatoes has started more than 5 years ago as a side project. At the beginning it only served two main purposes:
- it was an excuse to learn more about Mongodb
- it was a tool that helped me to stay focused during the first period of my new professional role as a freelancer
The first purpose has been fulfilled. I learnt a lot about Mongodb and Mongoid along the way, but in the end I must say that Mongodb has been a wrong choice from an architectural perspective. It's the wrong tool for the job. It's been misused to map a highly relational model on a document store and now I feel it's too late, in terms of effort, to replace it with a relational db.
The second purpose has been fulfilled as well. I started using Tomatoes and I never stopped. The only downside is that the tool doesn't promote a strictly application of the Pomodoro Technique®, but I really liked the fact that I was able to track the time I spent on different projects and, at the same time, I was able to apply a framework that helped me stay focused on one task at a time.
Open source software
I started posting about the tool and I received encouraging feedback. Other people from around the world were using it. At the beginning it was rewarding.
I decided to open source the project because I hoped to find collaborators and I wanted to let other people know about my work. I didn't think it would have never been a source of income and I never planned to spend a lot of time developing the idea further, so I thought that releasing the code would have helped keeping the project alive by letting other developers fix bugs and add features.
This choice has been a success from a personal point of view, but a complete failure from a project perspective.
Almost all of the the people that requested new features or bug fixing never actively helped by writing any code. Nobody has never even tried to host their own version of the app from what I know.
Project sustainability
When I started displaying ads to pay for app and db hosting I received numerous complains.
Only lately, when I started asking hardcore Tomatoes users for help, by supporting the project through Backerpass, I received a strong positive signal. There was people willing to pay to continue using the hosted version of the project.
I'm very grateful to these 6 heroic users, excluding me, that are willing to pay to use a tool that they consider useful, but I don't consider fair that 7 people pay to keep alive a project that is being used daily by at least 100/150 people.
That's the main reason why I'd like to make http://www.tomato.es a paid only service.
SaaS
This proposal includes a plan, and promotes discussion, on the topic of making the official hosted version of the project a paid only service.
People who are not willing to pay could either stop using Tomatoes, host their own version of the service, or use a unofficial hosted version of the service.
Pricing plans
I have two pricing plans in mind:
- 24 $/year
- 4 $/month
The reason why the yearly plan costs 50% less than the monthly plan, is that there's a fixed transaction fee that would highly impact on smaller transactions and because this would promote a longer commitment.
Alternative pricing strategy
I think it would be interesting to make people choose how much to pay for the service, starting from a minimum contribution amount.
This pricing plan would work in a similar way to how Humble Bundle works.
You can choose to pay, for your right to use the service, x
amount, where x
is greater than a minimum contribution amount. The amount chosen x = t + c
would include two values: t
amount that will go to the Tomatoes organization, c
amount that will go to non-profit organizations.
See also the Alternative revenue share strategy section.
Free plan
There wouldn't be any free plan.
In my opinion if you need a tool or a service, you'd be willing to pay for it. The key concept here is need: it means that you're not able to find any replacement that is good enough to make the transition.
Already registered users that are not willing to pay will lose all of their information after a grace period. During this transition period users will be able to download all of their data in a CSV format. After that period user accounts, projects, tracked tomatoes, and all the associated information, will be removed from the database permanently. This will help keeping service's operational costs at a minimum.
Current supporters
Right now supporters commitment is:
- Ben: $9
- Bud Manz: $7
- Jake Snell: $7
- johnkrane: $4
- Giovanni Cappellotto: $3
- Gabe Ragland: $3
- Anna C.: $1
The average monthly contribution is around 5 $/month.
I'd like to offer these users a special offer: 12
Free trial
New users will have a free evaluation period of 1 month when they'll be able to try the app.
At the end of the free month they'll start paying the monthly service fee if they don't explicitly opt-out or choose to enroll in the yearly plan.
This means that new users will be asked to fill in their credit card information upon registration.
This will lead to two main effects:
- new users conversion will drop drastically
- users that forgot to opt-out will start to pay even if they don't like the service
(1) isn't negative because I'd care only about people that are willing to pay. This would potentially exclude a lot of people that could find the service useful, but that are not incline to give their credit card info only to try a service.
(2) is very negative in my opinion because it happened to me the same a couple of times and I felt like I was being deceived to pay for a service that I didn't care about.
Sending notifications to warn a user about the imminent end of the free trial period, would help alleviate (2), but this means adding an email field to the registration form that would impact negatively on new users conversion.
Alternative free trial strategy
An alternative solution would be to ask for credit card information only after the free trial period.
I feel this solution would be slightly harder from an implementation perspective.
It wouldn't impact negatively on new users registrations conversion rate, but it wouldn't prevent registration of users that don't care about the service enough to even fill in their credit card information.
Another positive outcome of this strategy: users that forget to opt-out won't accidentally pay for a service they don't care about.
Transparency
A very interesting question is: how would we spend these money?
First of all let's define we. A couple of weeks ago I created the tomatoes-app organization to transparently collect code contributions, mainly on the web app and an upcoming iOS client, from me and other fellow developers.
We started working more consistently on the project from a couple of months, after the Backerpass successful campaign. That campaign asked for support to pay for hosting expenses, but it never included the time we're spending to fix bugs, improve existing features, and add new ones.
The main issue is that there isn't enough open source development force. Asking Tomatoes users to pay for the service would help the current organization members to budget development time, to make the app better and more useful.
The key aspect of the organization is to promote transparency.
Collecting money
At the beginning, the easiest option to collect money, in terms of setup costs, would be to use my personal account, the one connected to the payment gateway we'll choose.
To allow transparency we'll need to setup a public page where we list expenses and revenues. Revenues statistics will be aggregated to protect users' privacy. I'd like this to be a mandatory requirement for this proposal to be accepted and for the feature to be released.
Operational costs
Hosting Tomatoes costs money. The cost grows according to the number of people using the service.
Part of the money collected from subscription fees will be used to pay for app hosting, database hosting, domain registration, and other services.
Revenue share
All revenues, that is the amount remaining from subscriptions fees - payment gateway transactions fees - operational costs, will be shared between me and proportionally across the remaining organization members.
The goal is to give a reward for their effort, that is as little, or as big, as the number of paying users, to those people who actively work on the project to improve it.
Contributors would be given part of the revenues according to their involvement in the project. I would be responsible to decide amounts shared across organizations members according to their contributions value and the time they spent working on the project.
I would collect the remaining amount.
This could be seen as unfair, but since I'm the only founder, I'm the one who contributed the most, and spent more time working on the project, I think I'm entitled to get more than everyone else in terms of revenues.
I'd like to share these information transparently, showing, for each organization member, the amount they'll get from their involvement in the project, but I wouldn't like to make this a mandatory requirement.
Alternative revenue share strategy
An alternative revenue share strategy would be to share all, or part, of these revenues with third party charity or non-profit organizations. I don't know almost anything about these kind of organizations so I'm open to suggestions.