This page is part of a series on my first SaaS product called Quality Indicators Pro. The full series is listed below. Enjoy.
In 2010 I co-founded a SaaS product called Quality Indicators Pro. I learnt a ton of things during this time both from a technical point of view all the way through to marketing and sales. As usual with most developers who build a product it started with me 'scratching my itch'.
At the time I was working at an Registered Training Organisation (an educational organisation just below a University) and we needed to provide a report to the government on learner engagement during our training courses.
Being a software developer I quickly determined that the government supplied software was rubbish and would provide no meaningful data analysis moving forward. So I went to my boss and told him that I thought there was a good opportunity to develop a product here and if he was interested I'd like to bring the idea to the company.
This is where the 'scratching my itch' came in. It's a concept that the Open Source community does... 'they scratch their own itch'. They develop systems to solve their problems, the way they want them solved.
37 Signals (now called Basecamp) calls this 'Build software for yourself'. It's a very simple concept. If you have a problem you want fixed, it's highly likely that there are other people with the exact same problem. It's also likely that those people might just pay to use your solution for their problem.
That's what I was banking on anyway.
The system in it's simplest form was a data entry page with a single page report that the government needed. Pretty easy. To stand out from the competition though I'd need to incorporate the following features:
I'd also need to tackle a bunch of 'business' issues:
I chose very early on to go with a Linux stack as it would provide a lot more deployment options later on and at a more cost effective price. I then decided on the Ubuntu flavor of Linux as it is a very popular distribution and there is also a lot of documentation for it.
This was helpful for both my development machine (which I used as a VM inside Windows XP) and as the server when I eventually deployed to the production servers.
Speaking of the production servers I chose to go with Linode for my VPS hosting. Their pricing was excellent and they had pre-packaged versions of Ubuntu that I could boot on my VPS. They also have excellent documentation.
Obviously it was going to be a web based application so I decided to use Ruby on Rails (RoR) due to it being open source. It's mantra of 'convention over configuration' was also very appealing and I liked it's scaffolding tools which enabled rapid prototyping.
Initially I was developing on my Windows machine but the ruby interpreter was extremely slow, when running under cygwin, so I eventually setup a Ubuntu VM instead.
One of the things I loved about RoR was that it was MVC and I had complete control over the HTML output. None of the mangulation that ASP.NET WebForms was renowned for.
One of the awesome things about RoR is the amount of plugins available to do just about anything you can think of. These are called 'gems' in RoR parlance.
If you are a .NET developer gems are pretty much the same as NuGet packages, except RoR has had them for about 10 years :).
To get up and running quicker I made use of the following gems/plugins:
Accepting online payments was easy. We went with PayPal. Back in 2010 there weren't a lot of options and I didn't want to roll my own custom solution and have to setup a merchant account with our bank.
Setting up PayPal was a pretty cool technical challenge and I used several railscast.com episodes to guide me (#141, #143).
MySQL is the default database for RoR so I just went with that. The system I was writing was not going to be database intensive so MySQL was fine.
Previously I'd used subversion but git seemed to be the preferred source control tool for RoR developers. I also found the distributed version control concept to be fascinating.
I still use git and have found some very clever uses for it over the years.
I ended up using capistrano for deployment and it rocks! The basic concept of capistrano is that you run a rake command on your local development machine.
This causes capistrano to login to your production server and checkout the latest source code from the repository. Due to the fact that ruby is interpreted this works beautifully!
The technical side was really the easy part. You have features that need to be developed and you just do it. There were a few niggles here and there (the charting was difficult due to poor documentation) but generally it was pretty standard fare.
The marketing and sales side of things was completely different! I didn't have a lot of experience here except what I'd read during those years of wishing to produce my own SaaS product.
Determining how to price the product was hard. Our main competing product was free as it was provided by the government (this was the product I deemed rubbish). We were also targetting our product at the smaller RTO's as the larger ones usually had their own capabilities to produce the report.
I'd like to say we came at a pricing point via some scientific method or by surveying potential customers... but we didn't.
We simply picked four price points with each price point allowing you to enter more data. Pretty simple eh??
We also decided on a yearly subscription model as opposed to monthly. This was so we could get one years worth of revenue straight up front as opposed to a client dropping out after a couple of months. In hindsight I think this was a great idea as most SaaS products have an average subscription period of three months.
Along with this we offered a free 30 day trial so potential clients could try the system before subscribing. We didn't require any credit card details up front. A lot of SaaS entrepreneurs now recommend asking for credit card details up front to get rid of the tyre kickers.
With the coding prety much finished it was time to put together a sales website. I wanted to do this in the quickest way possible so I went with WordPress and downloaded a theme that matched the look and feel we where after. Thankfully I knew WordPress pretty well so I was able to customise a few things which didn't take much effort.
To go along with the website we created a short promotional video to demonstrate the various features of the product. Making a promo video is time consuming! You need a script, the screenshots and video footage you are going to display, a voice over and some backing music. Then you have to edit it all together with zooming and section highlighting etc. Technically the voice over was probably the hardest to get right as I didn't have a high quality microphone, I had to use the mic in my laptop! I'd probably use a service like Fiverr nowadays for the voice over talent. All in all the video turned out alright, you can view it here.
Whilst I was developing the product we had been compiling an email list and by the time we were ready for lunch we had over 4000 contacts. I used MailChimp to setup a number of email campaigns to send out to the list announcing the release of QI Pro. Again not really knowing anything about sales copy I did the best I could here and tried to match the look of the website. In hindsight this email could have been a lot better.
We were ready for the launch when we realised we had to improve our onboarding process so I got to work creating a number of videos on how to use the system. These took even longer than the promo video as they were signifanctly longer and had to be more concise. In all I created three videos with each being roughly five minutes long. I included links to these videos in the sign up email.
I created several "your free trial is expiring soon" emails and sent them out a number of days before their trial expired. In hindsight I should have had an email series the whole time of the trial for more engagement with the customer.
I also created a couple of follow up emails to try to find out why people didn't subscribe. These had limited success but are still a necessity to garner information if it is offered.
I learnt a ton of lessons during this whole process and there are a number of things I'll do differently when I release my next SaaS product (I'll have an MVP completed in a month hopefully):
cap deploy and my latest code is deployed.Creating Quality Indicators Pro was a very exciting and informative adventure! We've in no way set the world on fire but it reaps a tidy return. I also got to release a product from end-to-end, something which many developer dream of but few achieve, so I feel very priviledged.
So what are you waiting for? Go create your product... tally ho!