Archives for posts with tag: Hosting

Kickstart business development for your webapp

January 18, 10 //
3

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.

Manager friendly budgetting on cloud services

January 6, 10 //
3

So for some time, cloud computing has started transforming the hosting market. The market is really showing signs of big transformations coming up. New business starting from scratch easily take on this ‘new’ type of infrastructure for their online activities. Most of the traditional businesses need more push before going on adventure with for example AWS.

The traditional hosting market first was controlled by software giants. Open Source really changed this and already set the door wide open for basically anyone to join. Now with cloud services in addition, every developer can develop software and make this available per hour with flexible scaling. No server administrators and long term contracts needed.

Now. With these fairly new cloud services on the market, there is room for new tools and visions to sprout.

The impact of these changes go beyond your software and IT department. Managers and controllers need information they can use to run their part of the business and make decisions. With an arsenal of resources available, you should keep an eye on your costs and upcoming expenses. Maybe even more important you don’t want to have conversations like this happening:

  • Manager: ‘Yo! What is our burn rate on AWS?’
  • Dev: ‘Lemme check!’
  • *Opening console, typing all kinds of commando’s*
  • Dev: ‘Currently about 30 EC2 instances, 4 TB on S3 with 50.000 put and get requests yesterday’
  • Manager: ‘That’s more than last week! What is this operation costing us…!’
  • Dev: ‘How about you look up the prices and do some math?!’

There are a few reasons why you want to keep these conversations from happening:

  1. Annoyed developers
  2. Annoyed managers
  3. Managers feel they don’t have enough control on the costs
  4. Waste of time

Our need was pretty much expressed when I needed to calculate costs on a few project in order to bill one of our clients. I didn’t know where to start. Now, while talking about this with Michiel our minds got spinning. Why isn’t there just a simple tool too find out? Of course there are some ways to find usage. But basically our only notion of costs is on the credit card statement we receive. Amazon offers options to some extend, but is limited by their focus on developers.

While talking about this we came up with a little concept called ‘Qloudwatch‘ and Michiel starting building a first prototype. On his blog he has a more detailed list of features and screenshots of the app. Feel free to contact us to test the application. We want you to help us improve the service!