A bit over a year ago we launched Handicap Server, a Ruby on Rails web application which competes in the space of establishing handicap indices for golf players based on their past scores. Handicap Server collects multiple handicap computation methods, which include the official systems used in USA, Canada and the UK. Other formulae are suggestions from our users which were abstracted and generalized in a way they are useful to as many golfers as possible. In this article we present some stats and figures of our journey so far.
In 2013 we tracked 19,810 scores for 1,774 players. We more than doubled the numbers in 2014 with 4,435 players who registered 27,748 new scores throughout the season. All 2013 players are returning paying customers this year. Probably the numbers will still continue to grow a little bit by the end of the year getting closer to a satisfying 300% increase in traffic.
About 90% of the traffic came through our partner golf software company, Golf Genius. 10% of the users got to us through our Android application which we launched this year and can be found in the Google Play Store.
The Handicap Server fee is $3 / golfer / season which currently covers the entire hosting and maintenance costs of the application. Handicap Server is currently hosted on Heroku and the current traffic only requires a basic database ($9 / month) and 1 production dyno – a web process that handles requests ($0 / month). All other services we need (Sendgrid for sending emails, New Relic for performance monitoring, Papertrail for logging) are free of charge for our load. For long running jobs we simply use Heroku’s scheduler instead of using one full web worker. The only situation where we need a background process is when a user starts a new league and wants to upload a spreadsheet with past scores. By using the scheduler for this we only pay for what we use instead of paying for a full web worker – a process handling jobs which require more than 30 seconds to run ($35 / month).
We developed the Ruby on Rails application in 2013 and we only spent about 3 weeks of active development. Throughout the year we also spent a few days for maintenance and adding new computation formulae to the engine. This year we focused on mobile and used another 3 weeks to develop and launch the Android application. In the first year we spent a lot of time supporting our users to import past scores from spreadsheets of various formats and layouts. A lot of that work decreased in the second year. We offered our users a set of tools and templates so that they can add historical data themselves in our system via spreadsheet upload.
We started Handicap Server with a Romanian payment processor, Plati Online, but we weren’t too happy with it because of two main reasons. The first was that they did not have an API and we had to redirect users outside our web site. They gave us the ability to customize the look and feel of the redirect page a little bit, but it still was not the best experience. The major problem, however, was the credit card rejection rate, which was extremely high. Most of our international clients were not actually able to pay. We had to resort to PayPal, checks or direct wires. However, in 2013 this was the only option, although we started talking to PayMill at the same time. PayMill is the equivalent of Stripe in Europe. Both services basically offer an API for processing payments and they give you the freedom to choose the look and feel of your payment page within your app. PayMill also has an SDK for Android. In 2013 PayMill were not yet ready to process transactions from Romania, but we were among the first companies to be informed when they launched their service for this country. So this year we also made the transition to a new payment service and have been very happy ever since. PayMill processed all payments this season and the credit card rejection rate dropped to 0.
For 2015, we hope to maintain the same increase rate in traffic and have all our customer this year return for a new season. In terms of features, we are always hunting new ways of computing indices and extending our computation engine, but otherwise we do not see any major development going on. With a large suite of automated tests verifying our calculations, maintenance and bug fixing have required little time and we do plan to keep the application up to date with the latest Ruby on Rails versions and methodologies. We are very happy with where we are at after a bit more than a year and we strongly believe Handicap Server is a nice, sustainable niche business that allows us to experiment with software as a service in addition to our consulting activities.