We’re building a new webservice called Qloudwatch. It’s a webservice to monitor your cloud resource usage. For now it’s dedicated to Amazon Web Services. The objective is to give team members financial insight in their cloud usage.

Our approach to these projects is agile, basically we start building and model the service to the needs we have in our own company. For now that means:

  • Creating projects and easily add Amazon resources via the Amazon Web Services API
  • Add members to projects and track which instance is added by which member
  • Notifications for unknown instances (currently only for instances not added to projects)
  • Get insight in our non-billable and billable costs

We love work in progress. Meaning that we always will keep innovating our webservices. We think this also applies to the business model, in which we didn’t found that much innovation just jet.

In order to build and grow webservices, you need to test their profitability. But how does this work? You just can’t start with some premium versions of accounts and change them every month. So there applies a different strategy here.

A business model needs to be straight forward, prepared for growth and should scale with your webservice. One of the most important things to keep in mind is that your webservice and business model are connected, more than you think. So prototyping webservices is fun, but so is prototyping business models :-)

Here is how we work in order to bootstrap a webservice:

  1. Get your first users for the webservice and actively engage to research for new features and business oppertunities
  2. Introduce your first paying model, this should be the basis that probably never will be revised
  3. Reach break-even based on the monthly cost running the service (don’t calculate your time invested time and resources building the service)
  4. Turn your webservice into profit (this is where you take your past investments and envisioned future innovations into calculation)

We envision the following guidelines when we apply the steps above:

  • Quality of service is important, people are paying so there should always be a tested and stable version available
  • User feedback is guiding. Feedback leading to more paying customers is valued over gadgets, gizmo’s etc
  • Update often and fast, visible progress is valued over small tweaks. Paying customers that join early love to pay for the product, but love to see progress even more

This week I’ll write a post on how we envision the first business model of Qloudwatch.