How to build your own cloud application

How to build your own cloud application

Posted by Matthew Stibbe
Picture of Matthew Stibbe
on 17 May 2011
Advice Miscellaneous Technology Websites

I have just launched Turbine, the easy way to take care of business admin including HR records, staff time-off, purchase requests and, soon, expenses and timesheets. (Check it out – feedback welcome!)

It has been in development for a year. Here are some lessons about building a cloud application that I have learned along the way:

Turbine time off booking
Turbine screen shot showing time-off booking

See the big picture

What problem is the application trying to solve? Think on a human level rather than a technology level. With Turbine, I figured that nobody, on their death bed, wishes they spent more time filling in forms so my mission is to get rid of as much paperwork as possible by doing admin chores quickly and easily online. What is your vision? Do you have a good story or metaphor to explain it?

New call-to-action

Stick to what you know

I started a computer software company in the early nineties and it grew to more than 70 people before I sold it in 2000. We had to (re-)invent practically every bit of paperwork known to man: expenses claims forms, holiday forms, appraisals etc. etc. This experience is the guiding light for Turbine. We plan to automate all these growing business admin chores. What do you know about that you could turn into a great online application?

Know your enemy

For us, the near enemy is a bit of paper and a hand-made Excel spreadsheet. This is how our target customers do most of their routine admin today. We’re targeting growing businesses up to 250 employees (and to some extent divisions and regional offices of much larger companies). The distant enemy is, to some extent, Microsoft SharePoint and, to a bigger extent, big HRMS systems like PeopleSoft. Not that we compete with those guys directly but it’s always good to have someone to throw rocks at. Who is your near enemy? Your distant enemy?


Although the actual application is custom-coded in Ruby on Rails, the front-end site is built in WordPress. It is easy to use, extensible, free and you can find a million developers, writers and designers who know how it works. It makes website development and, more important, rapid evolution much easier. Any CMS that doesn’t allow for very rapid prototyping, copy editing and design changes is a broken, bad CMS. Your website will never be finished. You can never stop work on it. WordPress is the smartest way to deal with this. How often do you update your website?

Outsourcing and offshoring

Turbine’s main development team is in Ukraine and our testers are in Rumania. With Skype and online tools, distance doesn’t matter. The cost is lower than locally-employed developers partly because salaries are lower in these countries (and others favourite offshoring destinations) but also you don’t have to give them an office or cover their sick days etc. Back at IG, we reckoned on paying one pound in overhead for every pound we paid in salary. That becomes pretty expensive, pretty quickly. While Turbine has been an expensive project, I estimate it would have cost two or three times as much to develop if I had done it in the UK and four or five times as much if the developers had been on salary and in my own offices. Have you tried offshoring? What happened?

Discipline and process

However, distance imposes some cost. You have to be more disciplined about briefing and giving clear instructions in plain English. Also, you have to accept that you will need to do some bits of work over because of misunderstandings. Small businesses can use online sites like Elance and Guru to find and manage offshore talent, but for big development projects you probably need local technical management and some project management expertise to pick the right developers and manage them properly. However, process is like salt. Too little or too much can ruin a meal. You need to add the right amount. What processes do you use to manage your business? Do you need more or less?

Understand your target market

I did some detailed research into SMBs in the UK and US, their IT buying habits, priorities and concerns. It helps that I write a lot about SMBs for some of Articulate’s clients and this gives me access to useful research but there is also a lot online. The Office of National Statistics and the British Library, for example, has a lot of valuable data. What research have you done on your target market?

Overestimate the schedule

You can have any two of fast cheap or good. The first 90% of the project takes 90% of the time. The last 10% of the project takes the other 90% of the time. Accept these two facts before you begin and you will avoid a lot of heartache. Trust me on this! You should be able to get a working prototype of a simple online application done in 1-2 months, but adding the front end, terms and conditions, marketing copy, payment processing etc. etc. and then testing the app and refining takes much more time. For a more complex application, expect to spend about 2-3 months on prototyping and another 3-6 months or so on development. It probably pays to budget on throwing away your prototype and starting again at least once, although this didn’t happen with Turbine. What rules of thumb do you use when you estimate a schedule?

Lexus, BMW or Ariel?

Think about your pricing model. If you buy an Ariel Atom, it does one thing – speed -excellently but it has no windows, doors, body panels let alone a radio. If you buy a BMW, you get a great car but you have an option list that can add thousands of pounds to the price. If you buy a Lexus, you get almost all the options you want included in the price. For Turbine, we have a broad-featured, one-price-for-everything Lexus model. Other online apps follow BMW and charge extra for this and that. A few are like the Ariel, fast, focused and deep. Which model are you?

Launch is the start of the journey, not the end.

Okay, so I have a shiny new online app. It’s easy to focus on launch as the finishing line in the development race. But actually, it’s just the starting point of a much longer and more rewarding journey. There’s a big difference in mentality between building and running. Now we have launched, we’re focused on 1) telling people how Turbine can help them, 2) adding new features (expenses and timesheets coming soon) and 3) evolving and improving the site and front end to make it better. Are you building or running?

Know what you don’t know.

My other business is a marketing company (Articulate Marketing) but it works for big, big tech companies like HP and Microsoft. One challenge I have is to figure out how to translate that experience into building a new brand and reaching out to smaller businesses on a wider scale. So, we’re looking at search engine marketing, social media marketing and guerrilla PR. Also, my technical skills are very rusty – I haven’t coded anything in nearly 20 years. I don’t need to for Turbine but I do need to understand what my developers and testers tell me. Crash course coming up, I think. The third big challenge is to figure out what data is meaningful, how to track it and how to use it as a guide to action. We need to build a sort of business dashboard tracking clicks, traffic sources, conversions, user feedback and so on. Right now we have a great bug tracking system (Lighthouse) and a good proprietary system for capturing user stories in the development process (Tracker) but this is a new thing. I’m looking at Google Apps and Microsoft Office 365 as tools for sharing and monitoring this information. What don’t you know about your business? What do you need to learn to improve?

New call-to-action

See also: Articulate's tools

Related service: Websites