So we’ve been doing some client work at Firmhouse and we love it. We love it because it’s a good learning school. You get involved in projects you normally wouldn’t be involved in. You experience how other companies work at a fairly close distance.

But today I want to write a bit how we, as a bootstrapping company, effectively are bootstrapping with client work. Our vision was to bootstrap with our own products, but as it turns out this is quite hard. So we’ve been actively searching for how we can effectively combine client work with our own projects. A way in which we can build and test our products without outside funding(s).

Our approach to client work is to be ‘product oriented’ instead of ‘project oriented’. When we first meet with a client we directly start scoping the product, not the project. We do this because they’re not asking us to build a solution for them, they’re asking you to build a solution for their customers or users.

Point your vision from delivering a client project to deliver value to their users. As a web company working for clients you’ll experience that a client never has a correct articulated end result. End results always evolve. It’s this change that’s ‘evil’ in most project management methods. That’s because the process isn’t created to accommodate it. When clients request changes, it probably is because they’re learning more about the end-user and how they can capture the value of the product. It’s just the people that pay your bills being concerned that their product is of value to their end-users.

And so you should be concerned too.

Let go of the illusion that you’ll ‘do’ a few clients for a couple of months and then start building your awesome product for a few months. Make your own products and client products work together. You’ll have periods in which you can observe how your product is being used. You’ll have times in which you need to regain focus and need to think outside the box to come up with creative solutions. So why not think in the box of someone else, it’s outside you’re box and you can make some money.

We do this by working in timeboxes. We plan all of our work in timeboxes of two or three weeks (changes over time). We tend not to look further than 1-2 timeboxes. This comes from experience, within those two timeboxes we can deliver two or more working software updates to a client. These updates always instantly create change in which we can accommodate by not planning to far ahead. What if a client requires us to give a fixed end result? We commit to deliver a working product for end users by a certain date.

My advice for starting web companies that want to bootstrap:

  1. Deliver on products, not projects. Dig into your clients questions and start scoping the product. Working products deliver user value (equals the happiness factor of the people paying you).
  2. Release early and often. There is no such thing as building off site for 4 months and perfectly deliver something that (fully) satisfies users. If your client doesn’t accept your product, there is no payday. Where there is no payday, there is no money for the months planned to build your product and your back to scratch again.
  3. Take your lessons learned while building your own products to your client products. Explain a customer the concept of ‘Continuous Deployment‘. We like to push quick updates to the live versions of our client products. Imagine a user asking for a real small and feature.After validating what the client and his users want, push it an hour later to their product. They’ll be blown away. I can assure that there aren’t that much big web companies out there that will do the same.
  4. Work for the love of products. You need a minimum cash-flow that barely keeps the lights on. This gives you advantages like not developing big spending patterns and being able to easily switch to living from your own products when they’re ‘ramen profitable‘.

I’m looking forward to hear from other startups bootstrapping this way. We’re developing a model for this kind of startups which I will blog about more often from now on.

This web service called YouNoodle reeled me in with their ‘Startup predictor‘. I mean, an algorithm that predicts how successful a startup will be or how much it will be worth in three years. Sounds like too good to be true. I’m not able to judge what those digits are worth, but the environment YouNoodle created is very interesting.

It’s a simple index of startups around the world. The startups are scored with an algorithm and data from multiple interesting sources. The last couple of days I’ve been checking out YouNoodle for a couple of times. And there is some interesting information there. Of course you should question how reliable the data is and of which use the data can be. But it’s interesting to see how information between startups relate.

Algorithms, algorithms and algorithms. They are the centre of what YouNoodle provides as an service. And YouNoodle is not the only one. More startups need algorithms and mathematical analysis for the core of their service. In order to give users / customers good advice solid algorithms are needed. These algorithms are custom and for many of us very complicated.

There are some good examples of big companies that get a math nerd or dedicated math officer in an advanced stadium. Google has dedicated people developing their core search. Even more interesting, they have their own economical expert because AdWords is an economy of it’s own.

In order to compete we’ll start to notice that getting math people in the early stage of your startup is important. Maybe not only for your technical startup, but also your next little web service might profit. Think of the possibilities when differentiating using the power of Math. And not only based on concept, adoption or integrations.

I’m really eager to know if there are startups out there that have dedicated math experts in their team.

A lot of time of web startups is devoted to find the right product to sell to the right customer. While there are enough methodologies for technical development of products, there are only few methodologies for finding the right customer. Most of the old marketing methodologies don’t apply to web startups.

So there is this Customer Development process which I’m researching to use within our company. Customer development is under development by Steve Blank, and of course loads of other smart people. The reason for him to develop this process is his experience within startups that most of the startups fail because of bad marketing and business decisions.

Now there is a lot of discussion within companies in the terms of marketing and business development. Most of the times it’s referred to as ‘the suits’. People that take a big stake of your company and go out to lunch and play golf. And with all their time and money spent still there hasn’t been a single sale of the product. Which of course is ridiculous.

So early and repeating customer collaboration is one of the basics of Customer Development. It fits within ongoing trends we see on the internet and also the new generation working on awesome web products. That makes it a good weapon against the ongoing ‘negative’ rage against marketing.

What Agile Development has done for software development, customer development can do for marketing / business development.

A good start is to shape up a vision for your product / startup. Without that it’s just hard to sell. Having a central vision makes it easy for the people within the project to work independent, but even more important, to sell it to your first customers.

As Seth Godin states in his book The Purple Cow, your early customers / evangelists are the real sales people for your product. They spread the word about every little aspect of your product. Interesting part of this is that these people are more interested in your vision and future plans with your product.

Best examples here are the iPhone and iPad. The iPhone shipped early and lacked functions that needed work and weren’t released yet. Even simple features that other cheap phones had. But the vision presented with these products is what triggered early adaptors world wide to line up in front of the apple stores and buy an iPhone. The same is happening with the iPad. Without even touching or seeing the product, analysts determine that around 150.000+ iPads were sold in the first 60 hours. Crazy right?

Not if you think about it as early adaptors investing in a vision. It works for a lot of other startups too. A short and good talk about this is by Sheryl Sandberg. She talks about her experience at Facebook and her quest to work find gratification in her work at commercial companies.

Her tip: Make it personal and Make it work.

I started this week with a blogpost about kickstarting the business model for your webservice. Small companies start new web services on daily basis and need to turn a profit as soon as possible. For them  paying customers are one of the most important metrics to see if your service gains traction.

Qloudwatch gives non-technical people insight in the cloud usage by their team or company. Companies that run multiple projects on one Amazon account have a hard time breaking down the cost-structure of their operations. By gathering the historical data of amazon the costs per project can be mapped and tracked.

We’ve chosen to give Qloudwatch a de-central architecture. Basically this means that every individual has a personal (free) account which can be used to monitor his own cloud. Amazon resources will be grouped by projects, which can be created by users and shared with others. So we didn’t put corporate accounts in there, yet.

Qloudwatch will start as a monthly subscription based service. At first we’ll introduce three accounts. One free and two payed.

  • Personal plan (free account): 1 project, monitor 2 EC2 instances per project, no sharing options on projects
  • First payed plan: 4 projects, monitor max. 6 EC2 instances per project, sharing projects with max. 5 others
  • Second payed plan: 8 projects, monitor max. 12 EC2 instances per project, sharing projects with max. 10 others

The plans above are the base subscription model. We envision more options in the plans in the future (for example we add S3 and other services). Also we’ll introduce alert systems that give alerts via various channels (payed and free). More information on how the business model evolves will be posted soon.

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.

When developing new businesses or web services most of your time goes into planning. During the planning phase, people collaborate and take decisions based on the information available to them. Combined with their visions they decide what needs to be done and when it needs to be finished. Resulting in overcomplicated long documents and compromises so everybody stays happy developing the plan.

Described above is how I see traditional planning processes. Not particular bad of course, markets like the medical industry have compliance obligations and thus it’s hard to be agile (not impossible). This post is about one of the important aspects of running agile projects: decision making.

I’m taught to plan projects in advance. Describe what we’re going to do, what the goal of the project is and when it needs to be done. After some projects in school, I already learned that it’s just not the way to go. The plan changes all the time and time will never be on your side. The point here is, that when you change plans you need to update all your documents and re-run it through the complete team. Making it a complicated and dull task. Project managers should be working on stimulating collaboration in the team, not (re)writing documents.

The style above is based on developing to ‘point of plan‘. In other words, you work to create what is fully envisioned in the original plan according to schedule.

For every project success is determined by execution and results. You only reach good results with the right execution. Projects are successful when the end result is accepted by the people that have to work with it / use it. That’s why it’s important to stay in touch with the end user. They need to ‘buy’ what you’ve build. If they won’t ‘buy’ it, you’ve been building your beautiful plan but eventually end-up failing your project.

The economy is a turbulent place. So every piece of information available to you in order to create a plan, is probably old by the time you’re four weeks into execution. Methods that embrace change and promote to work independent are needed. Within the project team there needs to be a central understanding of what is build and what the project envisions. Plans should provide the minimum information that people need to make independent decisions.

The goal in these projects is reaching ‘point of sale‘, which means that a project aims to appeal an audience that accepts what is created and starts using, promoting or buying it.

Be agile, not rigid. Get the right people that know what they’re doing and trust them with making their own calls and decisions throughout execution.

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!

On Thursday last week I’ve attended to the Amazon Startup Tour in Amsterdam. The day was about the services Amazon is providing to run webapplications and websites. Amazon Web Services (AWS) range from computing power, data storage to database services (and more). Two important reasons to use the services are scalability and uptime.

At the event a few dutch startups presented their great applications and how they use Amazon to run them. Afterwards there was time to ask questions to the starups and later on to Werner Vogels, CTO of Amazon. One of the most interesting questions was about the data that startups store at Amazon. Martijn de Kuijper of Qash asked:

How do we tell our users that we don’t know where their data is, except that it is “in the cloud?.

The answer to the question is that all data from Europe on AWS is stored in Ireland, guaranteed. Therefore the data will be under the jurisdiction of Ireland. So another question came to mind. In essence, AWS is ‘controlling’ the data of our clients. For example what will happen when a client decides to delete his account. What will happen to his data? We asked this to Simon Brunozzi (European Envangelist of AWS). He told me that they always have been executing audits on the data of Amazon.com and also AWS. Recently a security whitepaper is published about this.

I think cloud computing is providing great advantages when you’re building a web application or starting an online business.

No let me rephrase that.

Using the cloud for your applications will remove a lot of constraints and will break some traditional rules of business development and IT management. Starting your online business will be cheap and above all will provide infinite resources at a click of a button. You can build web applications very agile, but the business wasn’t that agile yet. AWS and other cloud services make running your infrastructure and business very agile.

Martijn de Kuijper mentions this in a recent blogpost:

Again, I personally believe that Amazon offers a great service and I do trust them in such a way that I wouldn’t mind “sending” them personal data, but I think for a customer it’s a big step to know that I if they took the first step of uploading their data to  for example our server, their data is then stored on external servers.

First of all, I believe that a customer always is putting his data external. For example we’re running Tweetburner on our own server. For us it feels as an internal server (we can drive to Haarlem and put our hands on it!!). But for the users it is as much an external server as if we would use AWS.

Probably they would even prefer AWS above us running our own servers. Not only has AWS more security, more experience and more resources. They run their own multi-billion dollar webshop on there. If AWS fully breaks down, their webshop is down too. That probably is the biggest devotion a single hosting company is doing to it’s own services.

Cloud computing won’t ‘fog’ our business, it will strengthen by allowing to use external infrastructure and resources with a click on the button. Something I couldn’t wish for more as a business developer.