How I created a SaaS service that brings me $ 1000 a month
Note: here it is told about the creation from scratch of a small, profitable SaaS-service and about bringing it to the state when it began to bring $ 1,000 per month. This has nothing to do with multi-billion-dollar unicorns startups; I just describe my experience with this kind of work. This is a simple, reliable and profitable tool that anyone can make for themselves. And finally - this web service was made for the domestic market of Russia, so I translated everything into English and into dollars for convenience. But, on the other hand, this experience is quite universal and can be applied everywhere ( link to the service ).
It all started with my other SaaS service called Postio , which I did to make it easier for people to search and publish content on their pages and in their groups on social networks. As part of my marketing strategy, I acquired and published on my blog a dozen articles on various topics targeted at the web service audience in order to get additional traffic from search engines.
Then suddenly Postio began to receive relatively large traffic from Google and Yandex (Russian search engine) with keywords that had nothing to do with Postio itself.
')
Analytical statistics of Google for daily traffic
This is where the actual story begins.
It is clear that people had real problems with this menu. A short review showed that many group owners on vk.com (Russian Facebook) use the graphical menu at the top of the group to redirect their audience to the most important parts of the group, such as reviews, pricing information and order form.
This is how the menu looks like.
As you can see, the groups in this social network eventually become a kind of shopping; Many people use them to run a business, so as not to have the hassle of creating their own stand-alone website. Thus, it was not just a bunch of random groups about kittens (although there certainly were many groups of this kind), and it was a small business that had some problems that could be solved more or less automatically. Obviously, they needed a solution so badly that they googled it quite often.
But it is still tolerable. To make the menu shown, they had to create it in the image editor, cut, and then build the menu using some wiki-style markup. This was definitely too difficult for them, and the execution of this work by someone from the side. $ 20 was a fairly common occurrence.
The usual menu creation process was something like this:
1. Create a menu image in the graphic editor and place some buttons on it.
2. Cut the image into separate parts so that you can reassemble them with the buttons on the left.
3. Upload these images to a group album or owner page.
4. Create a wiki page in the group and enter markup with images and links.
5. Post a post with links on the menu page in the group.
6. Fix it so that it always stays on top.
Not bad, right?
Now let's see what we can do to fix this problem.
First of all, I had to study the capabilities of the social network application interface (API) to determine which actions can be automated here and to what extent.
It turned out that this API can do everything that I need, with the exception of post pinning. But this is too much for MVP, so I decided to remove the following features:
1. Authentication.
2. Customize the menu to the requirements of the customer (user). Instead, the user is able to choose from a dozen pre-defined templates.
3. Payment processing. I could do it manually.
4. Automatically create a wiki page. The user can make the page himself, and then insert the wiki markup that my application has prepared.
5. Automatic post publication. Again - the user can do it himself manually.
Therefore, essentially, what I had to do was an image generator and a downloader. Here is how it looked after two or three days of work.
Main window
Very bad, I know. But that was enough to find out if users are ready to pay for such an automated solution.
The menu creation dialog is also, ahem, ... not very perfect.
Menu creation window
Yes, I was also a perfectionist. Now I sell.
This was comparatively easy in my case, since the available traffic was what I started with. So all I had to do was just put a couple of buttons here and there in the article and wait for the visitors to come.
It looked like this:
The first 10 days after the actual launch
Even without considering the sales statistics, you can see that users are very interested in this service. Keep in mind that this was just the “hey-you-problem-we-have-solution” type of traffic with a really weak landing page based on a free template.
Now here's some raw recent (or, well, well, not very recent) statistics from the database.
Turnover and contributions are in US dollars.
It seems, can not be called a great success? But it worked, and users were willing to pay. Although it turned out a lot of abandoned unpaid menus ( menus_created relative to menus_paid ). But in any case, this is simply a (very rude) MVP.
As you can see from the statistics, I played a little with the price, changing it from 6 to 4 dollars for the menu, trying to get some idea about prices.
Now that we know that our service is viable, it's time to find out what price users are willing to pay for our services. And this should be done on the basis of information, not “flair”.
I'll step aside a bit and explain why I chose to pay for each menu instead of the standard monthly approach. The uplink application interface (API) of the social network is largely unstable, and the subscription model would be catastrophic, as I would have to constantly compensate for damages to users who would be affected by errors in the API.
So back to the price. Split testing is the easiest way to determine the best price that is acceptable to users. Basically, I set a random price for each user during registration, and then I tracked every action associated with that price. The grid price looked like this (yes, I also added a price for updating the menu and many different functions, such as, for example, fine-tuning the design of menu items):
The format is array (creation_price, update_price)
I also deleted the e-mail from the registration in the system and made it implemented with one click in order to get more registrations (and statistics) from users. About a month later I saw the following:
What does this statistic mean? Pretty interesting stuff:
1. 1, 2 and 3 dollars for creating a menu and 0.5 dollars for an update are the most profitable prices.
2. The price of 1 dollar entails twice as many menu generations as the price of 2 dollars, and three times more than the price of 3 dollars.
3. A combination of 1 / 0.5 dollar is the most profitable for the average income per sale.
Despite the fact that the price of 2 dollars required much less effort with the same income as the price of 1 dollar, I decided to stick to the price of 1 dollar, because I wanted to give users the opportunity to create as many menus as they wanted, since each menu had what Something viral mechanism. I will explain this in the next article.
After I decided on the price, I decided to add additional features that users need. See how the menu creation page eventually looked like:
Although she looks a bit sloppy and rude, but she does her job well. And under the exterior there are no tricks - just a little PHP and Imagemagick. The whole process of creation took me two nights and gave me pleasure, since I had always loved working with images since my teen years. I still remember sleepless nights spent studying ray tracing and 3D programming with Delphi. Here, truly, - the good old days ...
First of all, I wanted to use what this web service started with - the existing SEO traffic from the article. Indeed, it already worked, so all I had to do was slightly increase the start button and make it more noticeable. Such a simple action gave me 150 visits per day.
But then I noticed that the web service itself began to attract the attention of search engines, so the total traffic was about 200 visits per day. This resulted in 100 subscriptions per day (on average).
Let's leave the boring text - here is the final statistics for November 2016:
Note that the Users column shows the number of users who subscribed on a specified day, not the number of users who acted on the site. The number of the latter is much greater due to repeated actions of previously registered users.
Can this be called a great success story? Hardly. But I hope that this story will be useful for those who hesitate in deciding whether to take something small and able to bring some income.
There are many nuances that have not received the attention they deserve.
What do you think should be clarified in future articles?
I'm going to share different techniques and stories, so if you like the article, follow me here at Medium or on my Twitter .
It all started with my other SaaS service called Postio , which I did to make it easier for people to search and publish content on their pages and in their groups on social networks. As part of my marketing strategy, I acquired and published on my blog a dozen articles on various topics targeted at the web service audience in order to get additional traffic from search engines.
Then suddenly Postio began to receive relatively large traffic from Google and Yandex (Russian search engine) with keywords that had nothing to do with Postio itself.
')
Analytical statistics of Google for daily traffic
This is where the actual story begins.
Identify the problem
It is clear that people had real problems with this menu. A short review showed that many group owners on vk.com (Russian Facebook) use the graphical menu at the top of the group to redirect their audience to the most important parts of the group, such as reviews, pricing information and order form.
This is how the menu looks like.
As you can see, the groups in this social network eventually become a kind of shopping; Many people use them to run a business, so as not to have the hassle of creating their own stand-alone website. Thus, it was not just a bunch of random groups about kittens (although there certainly were many groups of this kind), and it was a small business that had some problems that could be solved more or less automatically. Obviously, they needed a solution so badly that they googled it quite often.
But it is still tolerable. To make the menu shown, they had to create it in the image editor, cut, and then build the menu using some wiki-style markup. This was definitely too difficult for them, and the execution of this work by someone from the side. $ 20 was a fairly common occurrence.
The usual menu creation process was something like this:
1. Create a menu image in the graphic editor and place some buttons on it.
2. Cut the image into separate parts so that you can reassemble them with the buttons on the left.
3. Upload these images to a group album or owner page.
4. Create a wiki page in the group and enter markup with images and links.
5. Post a post with links on the menu page in the group.
6. Fix it so that it always stays on top.
Not bad, right?
Now let's see what we can do to fix this problem.
Creating a program with the minimum necessary functionality (MVP)
First of all, I had to study the capabilities of the social network application interface (API) to determine which actions can be automated here and to what extent.
It turned out that this API can do everything that I need, with the exception of post pinning. But this is too much for MVP, so I decided to remove the following features:
1. Authentication.
2. Customize the menu to the requirements of the customer (user). Instead, the user is able to choose from a dozen pre-defined templates.
3. Payment processing. I could do it manually.
4. Automatically create a wiki page. The user can make the page himself, and then insert the wiki markup that my application has prepared.
5. Automatic post publication. Again - the user can do it himself manually.
Therefore, essentially, what I had to do was an image generator and a downloader. Here is how it looked after two or three days of work.
Main window
Very bad, I know. But that was enough to find out if users are ready to pay for such an automated solution.
The menu creation dialog is also, ahem, ... not very perfect.
Menu creation window
Yes, I was also a perfectionist. Now I sell.
Idea check
This was comparatively easy in my case, since the available traffic was what I started with. So all I had to do was just put a couple of buttons here and there in the article and wait for the visitors to come.
It looked like this:
The first 10 days after the actual launch
Even without considering the sales statistics, you can see that users are very interested in this service. Keep in mind that this was just the “hey-you-problem-we-have-solution” type of traffic with a really weak landing page based on a free template.
Now here's some raw recent (or, well, well, not very recent) statistics from the database.
Turnover and contributions are in US dollars.
It seems, can not be called a great success? But it worked, and users were willing to pay. Although it turned out a lot of abandoned unpaid menus ( menus_created relative to menus_paid ). But in any case, this is simply a (very rude) MVP.
As you can see from the statistics, I played a little with the price, changing it from 6 to 4 dollars for the menu, trying to get some idea about prices.
Now that we know that our service is viable, it's time to find out what price users are willing to pay for our services. And this should be done on the basis of information, not “flair”.
Pricing
I'll step aside a bit and explain why I chose to pay for each menu instead of the standard monthly approach. The uplink application interface (API) of the social network is largely unstable, and the subscription model would be catastrophic, as I would have to constantly compensate for damages to users who would be affected by errors in the API.
So back to the price. Split testing is the easiest way to determine the best price that is acceptable to users. Basically, I set a random price for each user during registration, and then I tracked every action associated with that price. The grid price looked like this (yes, I also added a price for updating the menu and many different functions, such as, for example, fine-tuning the design of menu items):
The format is array (creation_price, update_price)
I also deleted the e-mail from the registration in the system and made it implemented with one click in order to get more registrations (and statistics) from users. About a month later I saw the following:
What does this statistic mean? Pretty interesting stuff:
1. 1, 2 and 3 dollars for creating a menu and 0.5 dollars for an update are the most profitable prices.
2. The price of 1 dollar entails twice as many menu generations as the price of 2 dollars, and three times more than the price of 3 dollars.
3. A combination of 1 / 0.5 dollar is the most profitable for the average income per sale.
Despite the fact that the price of 2 dollars required much less effort with the same income as the price of 1 dollar, I decided to stick to the price of 1 dollar, because I wanted to give users the opportunity to create as many menus as they wanted, since each menu had what Something viral mechanism. I will explain this in the next article.
Development
After I decided on the price, I decided to add additional features that users need. See how the menu creation page eventually looked like:
Although she looks a bit sloppy and rude, but she does her job well. And under the exterior there are no tricks - just a little PHP and Imagemagick. The whole process of creation took me two nights and gave me pleasure, since I had always loved working with images since my teen years. I still remember sleepless nights spent studying ray tracing and 3D programming with Delphi. Here, truly, - the good old days ...
Marketing
First of all, I wanted to use what this web service started with - the existing SEO traffic from the article. Indeed, it already worked, so all I had to do was slightly increase the start button and make it more noticeable. Such a simple action gave me 150 visits per day.
But then I noticed that the web service itself began to attract the attention of search engines, so the total traffic was about 200 visits per day. This resulted in 100 subscriptions per day (on average).
Let's leave the boring text - here is the final statistics for November 2016:
Note that the Users column shows the number of users who subscribed on a specified day, not the number of users who acted on the site. The number of the latter is much greater due to repeated actions of previously registered users.
Conclusion
Can this be called a great success story? Hardly. But I hope that this story will be useful for those who hesitate in deciding whether to take something small and able to bring some income.
There are many nuances that have not received the attention they deserve.
What do you think should be clarified in future articles?
I'm going to share different techniques and stories, so if you like the article, follow me here at Medium or on my Twitter .
Source: https://habr.com/ru/post/320292/
All Articles