This page is part of a series on my first SaaS product called Quality Indicators Pro. The full series is listed below. Enjoy.

1) Quality Indicators Pro. My First SaaS Product

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 Product Scope

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:

  • charting
  • more reports
  • data filtering
  • data entry tricks

I'd also need to tackle a bunch of 'business' issues:

  • pricing models and online payments
  • marketing
  • customer acquisition
  • customer onboarding

The Technology Stack

Operating System: Ubuntu

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.

Application Platform: Ruby on Rails

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:

Online Payments: PayPal

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 episodes to guide me (#141, #143).

Database: MySQL

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.

Source control: Git

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.

Deployment: Capistrano

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!

Sales and Marketing

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.

Pricing Models

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.

Customer Acquisition

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.

Customer Onboarding

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.

Lessons Learnt

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):

  • Make sure your development environment is fast. Originally I was running cygwin under Windows but it was extremely slow. I ended up firing up a virtual machine and loading Ubuntu.
  • Keep costs to a minimum. This project was completely bootrapped and was why I chose a linux solution for my production servers, in this case Linode.
  • Have a one step process to deploy to your production servers. Through the use of version control and Capistrano I simply type cap deploy and my latest code is deployed.
  • Make use of existing libraries. I saved myself a bunch of time by using existing libraries.
  • Keep the number of plans to a minimum and charge more money.We had four plans and everyone pretty much went with the cheapest plan. We should have either upped it's price or reduced the amount of data they could enter with it.
  • Only have a 14 day trial. 30 days is too long to wait to see if people will convert to paying customers. In fact they should be able to tell within a couple of hours of use whether they will use your product or not.
  • Get a list of qualified leads. You will want to launch to as large an audience as possible so gather email addresses whilst still developing the product.
  • Keep your leads interested. We should have reached out to our list a lot more. We basically got them signed up and never contacted them again.
  • Make use of social media. I wasn't big on social media back in 2010 so didn't use it at all. Our product was in a bit of a niche that wasn't really tech savvy but still it could have created some buzz.
  • Reach out to your niches 'celebrities'. Again our niche didn't really have any celebrities but I'll be doing this for future ventures.
  • Allocate a lot of time to work on your promotional videos. Getting the four videos done (one promotional, three instructional) took several weeks to complete and
  • Setup an email training course. Besides the three instructional videos there was no other help available. Sure the product was failry intuitive but you should help in whatever way you can.
  • Update your blog regularly. I did some blog posts but didn't keep them up. It doesn't exactly instill confidence when a blog hasn't been updated in a number of years.
  • Keep promoting your product. We still do regular email campaigns to our list and always get people signing up from each of these so don't just rely on organic growth.
  • Validate if there is a market. The last and probably most important lesson. You must validate whether a market exists for your product before you expend a huge amount of time on it. We didn't do this and managed to get lucky.


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!

comments powered by Disqus