vicholiday was the final submission to the App My State competition. The app queries the Victorian Tourism API for 4 essential holiday making services – accommodation, stuff to do, transportation and tours.

Elevator Pitch

The one stop shop for researching a Victorian holiday destination – get ideas on accommodation, activities, transport to and from and available tours. Add individual items to a short list, print the list out and have a reference when booking.

Concept

The light bulb moment for this app occurred when I was inspecting the many sites utilizing the Victorian Tourism API. They all seemed to use the API as an additional feature to their site/app – not as the main feature. I wanted to create an app that was entirely based on the API (a very bad idea which we will discuss further on).

I also wanted to see how much red tape I would have to go through in order to gain access to the API. In fact, the process wasn’t too bad – an application email, a response with 50 pages of documentation that had to be read, a phone interview, followed by an acceptance email and appropriate credentials.

I then figured that not many others would be using this API – possibly giving me a better chance of winning the overall competition.

Research

My research consisted of inspecting the different sites/apps that were using the API and how they were using it. I wanted to create an app that encompassed the different parts of researching a holiday destination – not just one.

Outcome

I was quite pleased with the outcome of the app/site. The app consisted of only a couple of screens. The main screen showcased snippets of the different components - Accommodation, Stuff to Do, Transportation and Tours. Sorting and accessing in depth information about a particular feature was obviously available.

The main feature of the site was the “My Planner” section – a simple but effective way to short list components and view them all from a convenient portal.

Unfortunately since the end of the competition my API access has been revoked, therefore, the site looks very bare… In fact – there is nothing to display. (I should’ve taken more screenshots…) I can’t even link to the screenshots taken for the competition – as the site no longer exists.

Monetization

Not really – I mean, it’s all free data available from Tourism Victoria.

If the site was re-designed and could accept bookings – a booking fee could be charged, however, for this to be a reasonable revenue stream the site would need serious traction. A Victorian Tourism site with serious traction? I don’t think so…

Lessons

There is a very important lesson to learn:

1. Do not base your entire site/app on another site’s API or data unless there is a contract in place with serious data access clauses. The fact that the the vicholiday site is bare doesn’t cause me any serious harm (other than not being able to show you what it looked like).

Unfortunately, there could be serious implications for a site that hinges it’s main revenue stream on data access APIs. Delizzy is an app I built that solely relied on the Delicious.com API – which at one point was throttled.

This is the second time this lesson has come up. Take note!

Again?

Definitely – but SOAP is a real bore… You can check out vicholiday at – http://vicholiday.greenlemon.com.au – althought, there won’t be much to see…

Elevator Pitch

censusheat is a simple, visual and informative app that showcases census data for postcode regions/polygons.

Concept

This app was my third entry in the the App My State competition in 2010 – which was a Victorian Government initiative to give innovation in the Victorian state a kickstart.

I wanted to create an app that was purely map based – since I wanted to explore the Google Maps API in depth. All Google APIs are very powerful yet I rarely see many innovative and complex uses.

HTML + Javascript were the obvious technologies for such as simple app. IMHO, these were the only choices – fast loading, cross browser and lean.

Research

The simplicity of this idea was the reason behind little or no research being conducted. I did stumble upon similar sites – all in Flash. :)

Outcome

The most complex part of this app was getting hold of the polygon information for all Victorian postcode regions. Once I had these, I created KMLs for each particular dataset that I wanted to visualize. I did this by re-using the census information I had from building census/heat. I used the postcode to extract the information and populate that particular KML.

The outcome was a simple to use and informative site which was fast loading and full of useful information.

The app is comprised of four different heatmaps – they are: Monthly House Repayments, Weekly Rental Repayments, Weekly Income Repayments and Postcode Population Density.

I thought of several useful scenarios for the app – one being: to identify suburbs that are going through the gentrification process for potential property investment or home buying.

Monetization

Other than Advertising – there are no real monetization strategies I could see for censusheat in it’s current state. There really didn’t need to be any. I looked at it in terms of  ”What part of censusheat would I pay for?”

If the app was well received by researchers in any field, financial/educational/etc, and gained traction, I would expand it to include more comprehensive heatmaps – leading to a small, one time subscription fee.

Lessons

Other than learning the Google Maps API and more core Javascript – there weren’t many more lessons learnt while building this app.

Again?

Of course! It was such a simple app to build that delivered, in my opinion, really good, but limited, information – I would do it again in a heartbeat. In fact, any education/research institutions want a custom heatmap derived from census data? :)

You can check out censusheat at - http://censusheat.greenlemon.com.au

Elevator Pitch

Watergeddon is an in your face, albeit – impossible, representation of a water storage doomsday countdown.

Concept

Watergeddon was the 2nd app built for the App My State competition and was designed to shock but educate. It’s a submission to the sustainability category – a category I thought would have the least competition and therefore the highest likelihood of a favorable outcome.

It’s a big, in your face counter, one which you have the ability to influence – interactive and fun with a dash of seriousness. A bit like me…

The app also contains a per postcode representation of water usage, because I love visualizing data. A graph showcasing common water usage in the home – did you know that a full load of washing uses up 140 litres of water? And finally, links to several water saving government web resources.

Research

Normally I’d discuss the research conducted about the competition, monetization research, etc in this section, however, this app didn’t need any of that. It was a simple data calculation and interaction app.
A little research was conducted when calculating the theoretical watergeddon. I researched all water catchments in Victoria and found their respective volumes – I then divided the total volume by total population * litres of water usage per person per day.

Outcome

I seriously thought, as simple as this app was, that it may have been in the running. It may have been, but it didn’t win. I was/am still quite happy with the outcome – it’s fast, it works, it’s informative and visually appealing.

Monetization

No way.

Lessons

There were two lessons I learnt while building this app:

1. That I definitely need to brush up on my Javascript. If it wasn’t for Ray Hilton and his Javascript ninja skills, I wouldn’t have finished this app.

2. Being part of a small group of apps submitted, I thought the app would stand out, get noticed and get attention. I was probably right – but the winner stood out just as much. Unfortunately there are no prizes for second.

For me, the lesson formula is:  lots of competition = harder to stand out. less competition = easier to stand out – but there are never any guarantees. A formula for common sense more than anything.

Again?

Definitely, although if I was to do it again, I would write the app using HTML5 (actually using HTML5 elements) and CSS3.

You can check out watergeddon at – http://watergeddon.greenlemon.com.au

Elevator Pitch

suburb/slice showcases 2006 census data in a visually consumable format – via charts, images and maps.

Concept

suburb/slice was developed for the App My State competition in 2010 – which was a Victorian Government initiative to give innovation in the Victorian state a kickstart. It was the first build for the competition – and my first app in PHP.

As part of the competition, the Victorian Government released, or made available, several datasets – including links to existing data  websites.

I came up with the idea while searching through these datasets and spotting a very badly organised Victorian Government Census site. I guess my initial thought was – if I’m finding navigating this site very difficult, the normal user would find it almost impossible…

Research

After coming up with the initial idea – the only research that I conducted before building suburb/slice was to research the entries of a similar run competition in New South Wales. Some of the winners created similar apps to suburb/slice – so I followed the leader for this one. There are many articles advocating that first to market is the best way to capture market share – whereas, others argue that you should never be first to market… So which one is it.

Outcome

The outcome was simple – this app wasn’t successful in winning any prize in the competition. It did however win – users.

I wrote the app in PHP5 and used the MVC framework – CakePHP. After writing a few apps in RoR – MVC was very familiar to me so that decision was a no brainer. Specifically I chose PHP and CakePHP because- 1. I have never written anything in PHP and 2. I wanted to host the site/s on a normal hosting account – not a special RoR hosting account. (Everyone supports PHP)

In my case, first to market was negative and positive. How? Well, by being second to market, the outcome wasn’t great (read below) but it did have it’s advantage. The developers that created apps for the New South Wales competition normalized a lot of the data – which made developing the site quite easy.

So, users – after a few weeks of the app being live I was made aware by friends that the app was placed on several “Research Portals” on public libraries’ sites. This was enough of a reason for me to keep suburb/slice up – people find it useful! Win!

Monetization

There were a couple of strategies I considered for suburb/slice. Creating an API that apps/companies could access for a fee is/was one. I think it’s still possible – but since the census is conducted every 5 years – in 2011, we’ll have new data, so I might wait for that census and reconsider. The second strategy was creating widgets the could be placed on third party sites – which would attract a small monthly fee. This was a strategy I wanted to use for a different app (post coming soon).

Lessons

There were no real lessons learnt here, except for:

1. If you have a strategy, try it out. I didn’t push my monetization strategies very hard.

2. Being first or second doesn’t seem to matter – it’s all about timing…

Again?

Definitely. It was an easy app to build – CakePHP is an easy framework to use and PHP was a great tool for the job.

I still have hope for creating a similar app for the 2011 data and really pushing the monetization strategies.

You can check out suburb/slice here.

Elevator Pitch

Listaurus is a collection of Top X themed lists.

Concept

Searching the web for the keywords “minimalist site design” yields Top X lists for the first 5 results… I wanted to aggregate these lists in the one place and present them for easy consumption.

I didn’t want to spend too much time on building a site – since I was working on something else at the time – but I did want to save these lists somewhere. Why not bookmarks? Possible – in fact, I built a site for searching over the content of your bookmarks. I didn’t go the bookmark route as I wanted to include content that wasn’t necessarily my taste.

Research

Sure – just do another search for the keywords “Top 10 Lists”… The research wasn’t very re-assuring. I could’ve gone the list creation route like Listverse, who probably do very well, but that wasn’t the idea. I wanted to bookmark lists – but on a site which could be shared.

Outcome

Let’s firstly talk about the tech: Listaurus is WordPress.  That’s right, wordpress turned out to be the ideal technology for the site (I launched Listaurus in 3 days). I also used Yahoo Pipes for collating the data and a bunch of WordPress plugins to help me publish the lists.

My biggest problem was the list data. I didn’t want to go out and search for it – I wanted it to come to me. And it does. I use Yahoo Pipes to collect the data from multiple sources, parse out the non list data, and pipe it directly me. I collect it, massage it, find an image for the it and publish it. :) Easy!

Monetization

Google Ads fitted directly in the sidebar, and WOW, did they look good. In fact I even started making a little bit of money having them on the site – until my wife clicked on the Ads thinking she was helping. The rest is history. No more Google Ads!  :(

Lessons

There are a couple of lessons to learn from my experiences with, as I call it, this “mainstream” app.

1. Explain to your family, that under no circumstances should they click on your site’s ads. They’re not helping.
2. Don’t burn out. I found that I was trying  to post too many lists a day. It’s a simple process but it’s time consuming and it burnt me out. Make sure the work load is something you can handle – especially when it’s repetitive.

Again?

It was thought of on monday, soft launched on wednesday and seen by you today. Of course I’d do it again.

You can check out listaurus at http://www.listaurus.com

Elevator Pitch

delizzy.com is a delicious.com bookmarks search engine. The app searches through the content, not just the titles, of your delicious bookmarks.

Concept

I came up with the idea for this app while using delicious –  the social bookmarking site. This app is a kind of”scratch my own itch” app – meaning it solved an issue I had/have. I’m a lazy saver of bookmarks, meaning that when I save a bookmark I’m not thorough – I’m quick. I don’t add tags, a description, etc which ultimately leads to information-poor bookmarks. This makes searching over my bookmarks very hard.

Search engines are information rich – they store loads of information about websites, index it and open the index up for search. Why not combine the power of search engines with your bookmarks – that way you can have powerful, lazy bookmarking…

Research

My research wasn’t extensive – in fact, there was only one other similar app out there – deliGoo. I was quite disappointed when I couldn’t install the app – as it was an Firefox extension only. So my research stopped there…

Outcome

I wrote the app in Ruby and used the Rails framework. This was my second attempt at RoR. It was a good opportunity to learn more about the semantics of both technologies. Choosing RoR did have some drawbacks – the app was slow.  There is a load of XML parsing/manipulation/creation happening in the background – as well as querying of the Delicious and Google APIs.

It did however work quite well – it did everything that I wanted it to do with a minimal amount of effort. I built the site in under 3 days. There were some technical gotchas – one being that Google caches each CSE (Custom Search Engine) – these issues were overcome though, some with a little bit of smarts and some with a little bit of trickery.

Finally, I submitted the app to techcrunch.com not really expecting it to be written about – but it was and it generated a massive traffic spike. Check out the article here. It was rewarding to see users using the app. There was only one issue – during the traffic spike, delicious throttled my API access… This meant users couldn’t get access to the app the first time they tried – ultimately being detrimental to app’s success.

Monetization

I wasn’t that concerned about monetizing this app – however, I did try. I tried Google Ads which failed miserably. The site is quite simple, with not much content – so when Google tried to serve contextual ads, no ads were very contextual… So I removed them.

Secretly I was hoping delicious would notice the app and possibly offer me a job… :)

Lessons

I believe this is the most important part, so here we go:

1. Choose the right tool for the job – I believe that RoR was the wrong choice. This lesson correlates directly with the one below.

2. Spending money on the right infrastructure would’ve fixed most of the performance issues (but choosing a different technology could’ve wiped this lesson out completely). One Mongrel instance was insufficient to serve an XML hungry app like this one to multiple users. Obviously…

3.  Communicate with API providers – and communicate early. It takes providers some time to arrange whitelists/etc – which is totally acceptable and fair. Delizzy is now whitelisted, but the opportunity for the app to become mainstream has passed…

Again?

Sure – in fact, I was just about to re-write delizzy using a very light Ruby framework called Sinatra, or even a Java framework called Play – but I won’t. Why? Delicious may be shutting down… Unfortunate.

If delicious wasn’t shutting down, I would certainly do it again. It was simple, inexpensive, not time consuming and useful.

You can check out delizzy at – http://www.delizzy.com – but, unfortunately you won’t be able to try it out. This is deliberate – I’ve removed the ability to login. Why? Until an announcement is made about delicious’ future – I’d rather create something new.

Before I begin with this post – I must warn you: The story is long. Trainerlisting consumed almost 8-12 months of my life. There were many failures and not very many successes – but full of lessons, and yes, I would do it all over again.

Elevator Pitch

Trainerlisting is a simple to use, self service, Australian Personal Trainer directory. The Personal Trainer profiles on Trainerlisting are filled with standard profile features: photos, videos, comments, ratings, etc.

Concept

The initial concept for Trainerlisting was born while I was running on a treadmill at my local gym. I noticed a pin-board of A4 printed PT profiles – and many gym goers huddling around trying to learn more about their potential PT. My thought pattern went something like – “Why would you huddle around, cramped, and squinting, trying to find out about a PT, when you could just go and check out the website, right?”

Wrong. The gym website didn’t contain any PT profiles! Why? There’s one reason I can think of immediately – PTs come and go. If you didn’t build your website with a CMS solution in place, you’d have to pay a developer every time you wanted to make changes to the PT profile pages.

It seemed like a great opportunity – build a site that would:

1. Give gym owners/managers/PT managers an easy way of adding/modifying/deleting  PT information from their website.

2. Modify this information in one place only and have it immediately push out to all connected sites.

3. If they have that information on their website, pull it into a directory and give the business another marketing outlet.

The idea seemed plausible, in fact, it still does. So what happened?

Research

Research in this case meant researching PT directory sites and their features. Wait – what? Can anyone see a problem? Without even realizing it, I skipped point 1 and 2 and went directly to point 3! First mistake, and first lesson – before even beginning development of the site.

I had a look at several competitors, one in particular established competitor that had years on me – albeit their focus was more on Gyms than PTs. Much of a muchness…

Even with these early signs (losing focus, an established competitor, not enough research) pointing to trouble – I continued. I was going to be an entrepreneur dammit, and nothing was going to stop me!

Outcome

The short: The site took months to build, had a few clients, made some money, took lots of my time and brain power, and then it was shut down. Was it as a success or failure?

The long…

The site took months to build. I built every feature that I could possibly build into it, so that when it came time to demo it to PT studios/Gyms/etc, I could win them over with its feature richness. Mistake 2.

I did the usual stuff that came with building a business. I created a brand which consisted of  an easily recognizable logo, a couple of tag lines and two PT characters (thanks Age and Brett). These elements were consistent across the business cards, marketing material and promotional material.

Once the site was built, I began the SEO strategy. I didn’t quite know the importance of SEO until a couple of months later.  Searches for PTs keywords I deemed important was low, so being first or second in search results mattered – it mattered big time!

Finally I began marketing and going out and seeing potential clients. I did letterbox drops of marketing material, mailed marketing material out, emailed gyms/personal training studios, started an SMS campaign (thanks Damian and Andy) and eventually got out and visited potential gyms/personal training studios. But what was I selling? Why was I doing letterbox drops? Remember the 3 features? Other than building a simple widget (which was the simplest implementation of the initial idea), features 1 and 2 were forgotten about.

At this point I had almost completely lost focus and forgotten about my initial target market – Gyms/Personal Trainer studios – not small ones – but medium to large ones – ones that didn’t have PT information on their website.

Monetization

Trying to find the right way to monetize Trainerlisting was one of the toughest parts of running this small business. Initially I followed the competition’s strategy (see the section about being focused) – and as an outcome the monetization strategy was very simple, a yearly fee. This was the only way a PT would get a profile on Trainerlisting, no trial for you (Reminds me of a particular Seinfeld episode involving the Soup Nazi). In hindsight I was pretty naive to think that anyone was going to signup at a yearly fee, without even being able to try it first.

The second iteration, of figuring out a decent way to monetize, yielded the (common) freemium strategy. I offered free registration that gave PTs the minimum set of profile features.  I chose a different route to my competitors – mostly, they gave away the profile for free, but charged depending PTs on how many postcodes they advertised their services in (again with the focus thing – selling to PTs directly wasn’t the idea). I decided that postcodes weren’t the right way to sell membership – it seemed, well, fickle to do so. At this point though, the yearly fee still stood.

Third iteration of the strategy was to still go the freemium route, but change the yearly fee to a recurring monthly fee. This was by far the most successful strategy as it produced reasonable results – more signups. It was at this stage that I built more features for the premium subscribers. I thought that if I was the produce the most compelling reasons to signup that more PTs would. Unfortunately it wasn’t the case.

There was another business case that targeted PTs which wanted to start their own small business – I would set them up with their own custom blog setup which included a subdomain, a wordpress setup, business cards and help on getting started.  Where did this come from? Why was I doing this? I’m definitely sitting here feeling frustrated writing this. Needless to say, this strategy had no legs. The price point was wrong, the market was wrong…

Overall, I found selling to PTs, especially on why it was important for them to have an online strategy, very difficult. PTs are more concerned with the real world, their clients and how to up skill themselves to get more clients – online sales strategies are somewhere at the back of their minds.

So what happened to the original idea of selling to PT related businesses – well, that came a very distant third on the list – it should’ve been at the forefront of what I was trying to achieve. I did try – not very hard – but I did try, however, by then I was already on a path of destruction.

Lessons

Where do I start…

- Don’t lose focus! This was by far the biggest mistake that I made. If I had stuck to my original plan and idea, maybe I wouldn’t be writing this post. The idea had legs, it solves a problem, but by losing focus, the idea morphed into something I that shouldn’t have been pursued for so long. The message here is very clear.

- Iterate and iterate often. I quickly found out the reason PTs weren’t signing up – and I changed the model. Granted, I probably should’ve figured it all out a little earlier than I did, but I eventually got there.

- Get out there and talk to potential clients about what you’re trying to do, how much they would pay for your services, etc. In this instance, PTs were not willing to pay, not matter what the feature set for the premium account was – maps, analytics, commenting, ratings, searching, flickr integration, youtube integration, personal blogs, etc.

- Just because marketing material is cheap in bulk, doesn’t mean you should order 1000 of everything. In fact I’ve still got a pack of 100 A4 pages of marketing material that hasn’t been opened. Refine your sales pitch, refine your marketing material – get the bare minimum to get started.

- Get out there and get as many NO’s as possible – it will teach you things that you can’t learn in front of a PC. I still struggle with this today. I’m a relatively confident person but getting out there face to face with somebody and trying to sell your warez doesn’t come naturally.

Again?

100%! An absolute given. The problem about hearing about the success stories is exactly that – you rarely hear about the failures. I learnt the hard way and I wouldn’t trade those lessons for anything. In my case I spent a few months without a full time job, spent a little bit of money, but learnt many, many lessons! In the scheme of things, this was a massive success.

Get out there, make mistakes, because standing still will get you no where… :)

My name is Adrian and I like to build simple, useful and innovative solutions to real problems.