I used LAMP to make a SaaS with $3700/mo profit. Here’s how.

Written by moskovski | Published 2017/02/01
Tech Story Tags: marketing | startup | entrepreneurship | web-development | saas

TLDRvia the TL;DR App

Here I’m going to share my experience on creating a SaaS webservice with a simple LAMP stack and making it earn $3700 per month (actually it made around $7000 before the Russian currency had tanked). This story has nothing to do with investors, the Silicon Valley gold rush, and über modern technology. Just a simple story from an indie developer about making a profitable SaaS anyone could have built. I developed this webservice for the Russian domestic market, so I’ve translated everything into English and USD for convenience. Otherwise, this experience is pretty general and could be adopted anywhere. It’s a blueprint.

Three years ago I decided to tap into social media marketing and the easiest way to do that seemed to start my own group in a niche and to try to grow it. Facebook was already getting competitive, so I started my test group on its Russian counterpart, Vk.com. I picked a very popular niche because all I wanted was to learn, not to dominate the market.

To add some context I should note that Vk.com had and still has a flourishing ecosystem of these groups which is profitable for marketers. The market that Facebook choked a long ago. So this bazaar was a perfect environment to learn and experiment.

An example of a group on VK.com

Okay, back to the group. The first issue I came across when developing my group was sourcing and generating new content. It was an image plus some text mostly, and most groups just copied content from their competitors, who in many cases had also copied it from somewhere else. Usually, it was the content of authors that were difficult to track and attribute the work to. Sometimes it was blatant plagiarism.

Anyway, I always hated manual labor and decided to make a little tool to help me scrape the posts of my competitors (who had scraped them from elsewhere anyway) and publish them to my group on a regular basis. Vk.com had a neat API so everything was super easy to setup. I scraped a lot of posts and designed a little interface that helped me go through them and remove inappropriate content, like the posts with links, obscene language, and very few likes. I’d also removed the posts that were obviously copyrighted.

The tool for scraping and processing posts for my group

I ended up with a scraping and publishing tool with its own database of high-quality posts relevant to my niche. Having this, I could spent zero time on content issues and could focus on marketing, which was my primary objective.

Although I tried to keep everything under the radar, one of my competitors noticed unusually stable and consistent flow of high-quality posts in my group and decided to ask me about it. I explained the system to her and she offered me something like $200 for it.

I turned the offer down and asked her to pay me monthly instead. She agreed.

That was the inception.

Building an MVP

My crude tool lacked everything a mature web service should have, except the core functionality itself. It had one big advantage, though—it had already been validated, so I could invest heavily in its infrastructure because apparently Vk.com wasn’t the only social network I was going to be asked to support.

Also, from my previous startup, I knew that I need a sophisticated statistics and logging system to track down and fix all sorts of bugs as promptly as possible. I realized that I’m going to have a lot of them because when your project depends heavily on other services, their bugs, become your bugs.

I made a brief list of features for my MVP. It was quite long because I decided to include some stuff I usually avoid in the minimum viable product, like automated payments and all the additional interfaces.

Here is what I needed and what I had had eventually:

The payment gateway. Since the startup was supposed to operate on the Russian market I picked one of the most popular gateways there, Robokassa. It would have been Stripe but they didn’t work in Russia and still don’t, and bothering with setting up a Delaware company was pointless, not financially viable and too much hassle.

Robokassa fees

Robokassa fees were far from optimal, and I’ve already replaced it with Yandex.Checkout but it was okay enough to start with.

Content classified by niche. I decided to start with just the three most popular niches and working from there. These included: business and motivation, male-oriented general content, and female-oriented general content. For this, I had created a spicy mix of public domain content, some supposedly copyrighted content from unknown authors, and the posts from the groups that gave me their permission in exchange for me including their logo watermarks. That was enough to start.

The publishing engine. Vk.com was the first and probably the biggest (remember, we’re not in the global market) social network I had to support. However, I realized that I’ll also have to support Facebook, Twitter, and Ok.com (the Russian Classmates.com copycat), so I needed to implement some sort of stubs for them. Eventually, I just made a single function that called the API methods of the uplink social network for each group ready to be serviced, and added it to a CRON job. The CRON job fired up every 15 minutes.

Here is the mock up of the function:

Yes, that’s a super crude and unprofessional approach. Perhaps, I’d better have used some existing queue solution, but as I always say, I don’t consider myself a developer and not knowledgeable about modern implementation. I do all programming myself at the beginning because it’s fast and gives me the opportunity to react to user feedbacks with supersonic speed. After that, I happily delegate this job to someone smarter than me.

Comprehensive statistics and logging. In my previous projects, everything usually went haywire precisely because of the lack of data to analyze trends and errors. This time I didn’t want to make that mistake and decided to collect as much data as I could from the beginning.

The monthly stats after a year and a half of work; rows represent the days of the month.

When it comes to statistics and logging it’s tough to overdo it. In order to make informed decisions, you need to have tons of data of every single part of your service, especially if it’s the pricing.

The billing. Some of the uplink social networks (yes, I’m looking at you, Vk.com and Ok.com) were unreliable, so I decided not to use the subscription model and opted out for charging users on a per-post basis instead. This way I didn’t have to worry much if I couldn’t deliver the content to my customers if there were some issues with the social networks.

When I had everything set and ready, it was high time to think about how to generate the first customers.

Launch

At the time I had very limited budget and to spend it on paid advertisement was insane. So I had to figure out ways to acquire users for free.

The objective boiled down to this: I needed to find a way to contact group owners and not get blocked for being spammy. Clearly, direct messaging wasn’t an option.

However, I noticed that groups had an interesting feature. Anyone could suggest a post to a group that after a review allowed the owner to re-publish. This feature had already been profoundly abused but if done properly, it could still work.

I picked a bunch of groups in the niches Postio (that’s what I called the service) had content for and started to suggest them posts like one in the screenshot below.

One of this promotional posts (just an example)

As I was a group owner myself I knew how to compose a compelling post that would pass the watchful and experienced eyes of most moderators.

Results were quite impressive, nearly 70% of the owners I’d suggested posts to, signed up to Postio. Around 60% of those who had signed up topped up their balance in the system. Some of them even reached me on social networks to thank for making such a product. Those were the most satisfying moments, I guess.

Beside doing this post suggestion trick, I also published a post in my own group and offered Postio to the group owners subscribed to it. I knew that many of them had been reading groups of each other to monitor trends, posts, and the ecosystem in general. That generated some additional sign ups and paying customers.

At the end of the month, I had these stats.

Top-ups and Revenue are in USD

That was nice, but I still hadn’t figured out how much I’m going to charge my customers. It was time to fix it.

Pricing

I had no idea of the exact price that users were willing to pay for this sort of job, so I’d just set it to $0.01 per post. However, as I said many times in my previous articles, this random approach to pricing is quite costly. Even the slightest mistake (whether it’s undercharging or overcharging) can easily cost you a fortune in the long run.

So I decided to apply my usual approach and to figure out the price that would bring the highest revenue. I assigned a random price from a predefined set to each user upon the sign-up and monitor all activities associated with each price.

Here is what it looked like in code.

By scattering the incTestValue method across the code I could collect all metrics for a particular price I needed.

After a while, I had these stats on my hands.

Remember that the original currency wasn’t USD so this is why the fee column expressed in dollars looks strange.

This split-test had revealed some pretty interesting points:

  1. The one cent price had the biggest number of published posts.
  2. The two cent price was the most profitable.
  3. It’s pointless to test prices bigger than two cent per post at the moment.
  4. People with the two cents price topped up their balance twice more often. That could mean that they were satisfied with their first attempt to use the service and had made extra top ups.

Anyway, two cents per post was the most profitable price at this stage so I went with it. That didn’t necessarily mean that it would always be the case. It’s probable, as Postio evolves users will be willing to pay more but it’s subject to another test later on.

Now, as we have our hard earned data-driven price, let’s scale it a bit.

Scaling up features

Besides increasing the number of niches and social networks my service supports, there were some other things I could do. A few customers asked me for some tool for processing the images that they attach to their posts. Features like rounding the corners, adding some effects, and placing watermarks. It was a perfect opportunity to upsell.

I had implemented a simple interface that allowed users to set their own image preferences. Each effect had its separate price and was added up to the base price of a post. Here’s what it looks like.

I’d say it was quite barbaric and stupid to charge users like that, but hey we all were young once.

The algorithm that processed these effects was pretty straightforward. It was just a function with a lot of arguments and some Imagemagick-based code inside.

I added extra columns to the stats table indicating what effects users applied and how often they did it. This feature gained momentum quickly.

An example of the stats is on the left and the growth dynamic is on the right

Also, I added a lot of other features like pauses, custom posts upload, and support for multiple accounts, but these details aren’t interesting so let’s fast-forward a bit and see what I did with traffic.

Scaling up traffic

I had a very limited budget of something like $500, so buying traffic directly wasn’t an option. However, I noticed search traffic was organically growing to the main page which had keywords that were related to my niche but didn’t belong to it directly.

After quick traffic volume analysis of those keywords, I decided to invest the whole budget into two areas: writing articles for the most popular search requests, and buying promotional posts from bloggers in my niche.

I collected the list of keywords that my users asked in search engines the most and hired a copywriter to create articles based on them. We produced “how to make a vk group”, “how to make a menu in a vk group” and others.

After the articles had been published in Postio’s help section, I negotiated special prices with the most promising bloggers in my niche and they made several posts about the service.

All this hustle had increased search engine traffic like this:

By the way, the majority of this traffic landed on one article about making a menu for a Vk.com group. That lead to the making of my another SaaS that I’ve described in this story. Take a look at it, it’s fun too.

To put the cherry on the cake, I’d also implemented an affiliate program. It was pretty simple: users had a unique link that they used to invite other users and receive 10% affiliate fee of their spendings. Nothing fancy but this source accounted not only for like 15% of all sign-ups but also got Postio some high-quality backlinks from various mediums. Which obviously didn’t hurt its search engine rankings.

It took 14 months to reach $3700 ($7000 back then) monthly profit and the only major loss was the depreciation of the currency this service worked with.

Conclusion

Making a profitable SaaS is never easy and it’s impossible to explain every aspect of it in a small article like this. But It’s entirely doable by almost any developer. You don’t need a partner, an investor, or even a great idea. Just start doing something and you’re inexorably going to stumble upon some issue ready to be solved. Nothing is perfect, and that’s good news.

I hope this story was of any help and as usual I’m open to any questions either here or on my Twitter.

Thanks for reading!


Published by HackerNoon on 2017/02/01