Digging my own Ditch

This article is part of a regular series on bootstrapping by Matt Rogers, co-founder of Aroxo. It continues from the previous post which looked at how to find off-shore developers.

Off-shoring your web-development is a great way to save money and, if you are bootstrapping a small start-up, it could be the perfect strategy to hang on to more equity and delay financing. However off-shoring your development is also fraught with risks, it is far harder to manage your development and communicate ideas, so it is vital to take proper steps to protect yourself. In this post I continue describing the system I’ve used several times in order to ensure that I get developers who are motivated, technically capable and trust-worthy.

You’ll find stages 1 and 2 discussed here.

Step 3 – Send the developers you’ve found a “Request for Information”

A Request for Information (or RFI) is a questionnaire to help you short-list developers. The objective of the RFI is to enable you to decide which developers can deliver your project in the right sort of price range. Your RFI should at least gather the following information:

• Hourly rates for different staff types
• Which currencies the developer can raise invoices in
• Whether they are prepared to set a fixed cost for the project (you want a fixed cost, right?)
• Between 3 and 5 customer references
• Information about the company (how long has it been running, how many people it employs)
• Information on their typical project (how big it is, how long it lasts)
• The development methodology employed and development technologies supported
• Whether they have a design house
• Their preferred development technology
• Any technology certifications which they may have
• a “difficult technical problem” which is related to your project, ask the developers to sketch out how they would solve it

I’ve included an example RFI in the documentation bank to help get you started.

When asking for references, try and get projects which are similar to yours. Also get a reference for a company which is physically near you and then arrange to meet up with them for a coffee and a chat.

Your RFI should also tell the developers all the key deadlines for the selection process. It ensures that the developer knows where they stand at all times, and it gives you targets and deadlines to meet yourself. When you issue it give the vendors at least 2 weeks to respond and an opportunity to ask you questions.

If you are worried about controlling your IP, then there’s no need to discuss what your actual business is in the RFI. However, you might want to describe in broad terms the type of business you are launching, or refer to some similar companies.

When you send the RFI out, update the vendor dashboard which you set up at the start of the process.

Note that not every company will respond to your RFI. Some companies will respond but fail to answer the final question, some companies will send you back documentation packs which probably contain the answers, but they’ve not bothered to put them into your format. All these companies should be immediately dropped from the list.

Step 4 – Short-list the developers

Two weeks after you’ve issued your RFI you should have all the responses you are going to get. I tend not to bother chasing any companies who don’t reply to the RFI and just stick with those that do. Your next step is to short-list the developers, you want to work through the responses until you have 4-7 companies to take through to the next stage.

Before you start short-listing the developers, you need to think about what your ideal company is. You might want to work with a small company, or you might be looking for a larger company with ISO or CMM certification, you may have a particular development methodology in mind, or you might want your system built with a particular technology, etc.  Collate all these thoughts to help piece together what you are looking for.

You are then ready to start “the sift”. First stage is to remove any companies which just aren’t right. Personally when reading through these responses I arrange them into three piles: yes, no, and questions. I then ask the questions and update. I continue to do this until I have only a yes pile and a no pile.

Remember to always check the references, this is one of the best signals of quality company. If they are in your country, arrange to go and see them, otherwise drop them an email. You want to know whether the developer delivered on time and to budget, if they still use them, if they’ve given them any new work and if they’d recommend them.

Keep working the list until you get between 4-7 companies. It is important that you don’t take too many vendors through to the short-list round as you don’t want large numbers of companies knowing what you want building. If you don’t have enough, approach more companies. Finally, ensure that you feedback to all the companies involved (good news and bad) and update the vendor dashboard to so can keep track of where each company is.

In next week’s post we’ll look at how to get a price for the development and how to select which companies is going to build your business.

Off-shoing your web-development is a great way to save money and, if you are bootstrapping a small start-up, it could be the perfect strategy to hang on to more equity and delay financing. However off-shoring your development is also fraught with risks, it is far harder to manage your development and communicate ideas, so it is vital to take proper steps to protect yourself. In this post I continue describing the system I’ve used several times in order to ensure that I get developers who are motivated, technically capable and trust-worthy.

You’ll find stages 1 and 2 discussed here.

Step 3 – Send the developers you’ve found a “Request for Information”

A Request for Information (or RFI) is a questionnaire to help you short-list developers. The objective of the RFI is to enable you to decide which developers can deliver your project in the right sort of price range. Your RFI should at least gather the following information:

• Hourly rates for different staff types
• Which currencies the developer can raise invoices in
• Whether they are prepared to set a fixed cost for the project (you want a fixed cost, right?)
• Between 3 and 5 customer references
• Information about the company (how long has it been running, how many people it employs)
• Information on their typical project (how big it is, how long it lasts)
• The development methodology employed and development technologies supported
• Whether they have a design house
• Their preferred development technology
• Any technology certifications which they may have
• A “difficult technical problem” which is related to your project, ask the developers to sketch out how they would solve it

I’ve included an example RFI in the documentation bank to help get you started.

When asking for references, try and get projects which are similar to yours. Also get a reference for a company which is physically near you and then arrange to meet up with them for a coffee and a chat.

Your RFI should also tell the developers all the key deadlines for the selection process. It ensures that the developer knows where they stand at all times, and it gives you targets and deadlines to meet yourself. When you issue it give the vendors at least 2 weeks to respond and an opportunity to ask you questions.

If you are worried about controlling your IP, then there’s no need to discuss what your actual business is in the RFI. However, you might want to describe in broad terms the type of business you are launching, or refer to some similar companies.

When you send the RFI out, update the vendor dashboard which you set up at the start of the process.

Note that not every company will respond to your RFI. Some companies will respond but fail to answer the final question, some companies will send you back documentation packs which probably contain the answers, but they’ve not bothered to put them into your format. All these companies should be immediately dropped from the list.

Step 4 – Short-list the developers

Two weeks after you’ve issued your RFI you should have all the responses you are going to get. I tend not to bother chasing any companies who don’t reply to the RFI and just stick with those that do. Your next step is to short-list the developers, you want to work through the responses until you have 4-7 companies to take through to the next stage.

Before you start short-listing the developers, you need to think about what your ideal company is. You might want to work with a small company, or you might be looking for a larger company with ISO or CMM certification, you may have a particular development methodology in mind, or you might want your system built with a particular technology, etc. Collate all these thoughts to help piece together what you are looking for.

You are then ready to start “the sift”. First stage is to remove any companies which just aren’t right. Personally when reading through these responses I arrange them into three piles: yes, no, and questions. I then ask the questions and update. I continue to do this until I have only a yes pile and a no pile.

Remember to always check the references, this is one of the best signals of quality company. If they are in your country, arrange to go and see them, otherwise drop them an email. You want to know whether the developer delivered on time and to budget, if they still use them, if they’ve given them any new work and if they’d recommend them.

Keep working the list until you get between 4-7 companies. It is important that you don’t take too many vendors through to the short-list round as you don’t want large numbers of companies knowing what you want building. If you don’t have enough, approach more companies. Finally, ensure that you feedback to all the companies involved (good news and bad) and update the vendor dashboard to so can keep track of where each company is.

In the next post we’ll look at how to get a price for the development and how to select which companies is going to build your business.

Aroxo recently turned a major corner in its development, we moved from closed functional testing to using real live alpha testers, people who’d never seen Aroxo before.

Without doubt, this is one of the most revealing, painful, and valuable stages in creating your start-up, so I thought I’d blog about it.

When launching anything you want ensure that not only does it work, but people find it easy and natural to use. Your own functional testing should cover the first objective, your alpha testing should cover the UI.

At Aroxo we’ve employed four different techniques to get the system ready for launch:

Not only is each stage different but you get different learnings from it. I discuss each stage below.

(more…)

A really effective way of boot-strapping your start-up is to off-shore and out-source your development. But doing this also carries risks, how can you be sure that you are going to get a developer who’ll see it through and has the right experience? This post lays out an effective process to find the right developer.

From starting the search, to the first developer writing code should take around 3-5 months and there may be further delays whilst you complete your documentation. In this article I’ll talk you through what you should be doing at each stage, and what the objective of each stage should be. Here’s an overview of the process:

1. Build a long list of development companies
2. NDA all the companies on the long-list
3. Issue a Request for Information (RFI)
4. Analyse responses and short-list the developers
5. Issue a Request for Quotation (RFQ)
6. Analyse responses and select a preferred vendor and a spare
7. Negotiate contract with preferred vendor
8. Commence development based on your documentation

This is a long process, and therefore I’ve split it up into 4 sections, these will be posted each week for the next four weeks. Any regular readers can relax – the whole lot has been written in advance, so there won’t be any 1 month gaps in between!

Finding a great development company is one of the most important decisions your company will make. Changing developers mid-way through a development is near impossible and so it is important that you select a company which you are confident has the ability to see it through. The purpose of this 8-step process is to stack the odds in your favour by finding out as much as possible about the development company before you sign the contract.

At several stages I’ve included sample documentation to give you more guidance on what should be included. You can download these examples from the documentation bank on Aroxo.

Before we start, one word of advice. Running a vendor selection process will involve giving a large number of developers bad news (and only one company good news). When I first started doing this I found the process of giving bad news quite unpleasant. It is, but it is still important to do it. Vendors are used to receiving rejections, so they tend to take it more easily than expected and I also find that giving the bad news, along with some personalised feedback is always much appreciated.

Step 1 – Build a long-list

Before we start populating a long-list, it is worth spending a few minutes getting properly organised as running a vendor selection process involves a lot of time, organisation and communication. I find it easiest to run these off a spreadsheet which we’ll develop going forwards. There’s a sample vendor dashboard included in the documentation bank.

Building a long list involves populating this dashboard. The aim is to get 20-30 companies into the dashboard that satisfy your broad requirements for the type of system you want to build. You want to make sure that each company has:

1. Experience in building the type of system you’re looking for (if you think your system is entirely new, it almost certainly isn’t, there will be parallels which you can look for, even if those are purely functional elements)
2. Experience working with start-ups
3. Offices somewhere in the world you are happy doing business
4. Experience in the technology you want your system built in (if you don’t have a preference, then ignore this)

By far and away, the hardest of these objectives to meet is the first. You may need to contact many companies to determine whether they have built a similar application to the one you’re looking for.

In order to find companies, there are a few tricks you can employ:

1. Use your network – ask anyone you know who works in the software industry for 2-3 development company recommendations
2. Use referral companies to provide connections and act as a filter
3. Use associations to help pinpoint development companies
4. Use tools like eLance, Scriptlance and Rentacoder to find developers
5. Use Google to help find companies
6. When you’ve found a company you like, do a reverse search for their homepage on Google to see if they belong to any associations with links to other companies

You may need to look through a large number before you’ve found 20-30 companies which can meet the 4 requirements set out above.

Step 2 – NDA everyone

You’re a start-up (I’ll return to this point later), so an NDA offers no protection. If you’ve got funds to sue a company then, frankly, they would be better spent fixing the mistake with a new developer. However, it is still essential that you NDA all the vendors, even though you are not going to be providing them with any confidential information (other than of your existence, just yet).

First thing you’ll need is an actual NDA. There are plenty you can download for free on the web, so I’ve not provided one. Read it to make sure that you are comfortable with everything included in it. If you’ve selected a lawyer at this stage, ask them to provide an NDA, but don’t pay them to write out a new one.

Email it to all the developers on your long-list and ask them to fax or scan signed copies back, make sure there’s a deadline for return in your email. When you receive one back, open up the Vendor Dashboard and update it so that you don’t forget you’ve received it. Then print it out and file it.

When you hit the deadline, ignore any further submissions, if the development company can’t meet this simple deadline they are not going to meet any further deadlines.

In the post coming next week I’ll detail how to write and issue and RFI and then short-list your developers.

Ok, so you’ve got an idea, you’ve got a limited budget and you want to start your own company. To keep control of costs you’ve decided to off-shore the development. Now what do you do? How do you go from idea to launched system?

In this post I’ll detail your first steps towards launch. By the end of it you’ll know how to build a mock-up of your business idea and write the most important document you’ll write for the company: your functional specification.

For a simple system this process should take you a month. For a complex build there will be a lot more research and your mock-up and functional specification will be big, budget 3 months of full-time work.

You may also find it useful to look at my overview of starting-up post, first in this series.

(more…)

The aim of many entrepreneurs is to take a business idea and convert it into a professional and functioning business on a low budget. This is typically called “bootstrapping” and it is fraught with potential pitfalls and dangers, but when done well can really help get a company going fast, professionally and without the founders having to give up much (if any) equity or bankrupting themselves.

Over the next 5-6 posts I’ll outline the process which I’ve now followed at several corporates and which I’ve honed to work with my own start-up, Aroxo. I’ll discuss what skills you’ll need, how to write your requirements, how to source developers and designers, how much to budget, how to agree a development contract, how to manage your vendors, how plan your release, all the documentation which you need and much more.

(more…)

A couple of days ago I struck on an idea for a new search system which would consistently produce results more relevant than Google. So in this post I’m going to detail the process I used to get this idea in the first place and others like it.

I don’t believe that ideas “just happen” or “pop into the head”, I’m very much of the view that we develop them with repeatable steps. This is what this article is about – how to generate ideas.

I started thinking about this by noticing that most good business ideas can be traced back to a source (which I call their “idea genesis”) in one of three ways, in this post I examine those three ideas, and then explain how I use them to generate new ideas, including the Google-beater I mention above.

(more…)

There’s a lot of talk about “Web 2.0″ on the Internet at the moment, in this post I try and cut through the hype and look, pragmatically, at what entrepreneurs need to do to use Web 2.0 to build exciting and valuable propositions.

In this post I’m deliberately looking at the impact which Web 2.0 has on users which makes it so appealing to a certain segment of the population. This information will help entrepreneurs know what to build into their propositions in order to take advantage of the opportunity today to steal a march on older style Web applications.

To bring the post to life I’ll be demonstrating how the principles I’ve uncovered can be applied to a classic Internet application – corporate email. I’ve arbitrarily chosen email as it is a example of an application which has not substantially changed in the last decade, by applying some of the Web 2.0 principles outlined below we’ll see how its feature set can expanded to make it more inclusive, fun and sticky.

(more…)

I recently finished a new book called Founders At Work by Jessica Livingston (available here on Amazon).

This book is a series of interviews which Livingston conducted with 32 different entrepreneurs and as such represents a very original resource for would-be entrepreneurs. The list included the stories of companies such as Paypal, Hotmail, Apple, Excite, Yahoo! and many more.

As a regular reader of similar literature, on balance I enjoyed the book. However it was by no means perfect. As the text is a verbatim repetition of her interviews, it is often difficult to follow and you quickly find yourself reading the book for one or two hidden gems of advice in the text. The interview with Steve Wozniak is a perfect example of this, there are several pages of text which describe how Steve worked tirelessly to reduce the number of chips on his circuit board designs. Whilst stories are ancedoctally interesting, they consume a significant proportion of the text and detract from the valuble lessons which we entrepreneurs would benefit from. They make struggling through the book a challenge and certainly make it harder to draw out the key lessons.

Whilst I would recommend that anyone who is in the process of starting up an online business would do well to read this book, frankly the nature of the text means that some effort and commitment is required to really draw applicable conclusions from it. The book would really have benefited from some sort of analysis performed by Livingston which helped guide the reader to the key lessons from each of the founders.

Overall – OK.

Over the course of the last two weeks I’ve started work on a new business (parallel running with Aroxo) and it occurred to me that getting to the point of starting the vendor selection process, from idea conception took around 10 working days. For Aroxo this process took something like 1 year.

I confess that when we were starting Aroxo I was working fulltime and so I only had evenings and weekends to spend on the business, but this does not explain the increased efficiency. This extra speed comes directly from the experience of launching Aroxo, quite simply for the new business I followed a tried and tested process which I’d already put through its paces for Aroxo (and other projects).

The process which I am about to describe is directly targetted at launching a business which is “bootstrapped” (i.e. self-funded) and where as much of the work creating the business is out-sourced. The process rough is:

Over the next series of posts I will detail precisely what we did at each stage, focusing in much more detail on what information was needed to get each stage started and what to look for from the output. I’ll provide examples for each of the stages and make it clear where it is possible to skip certain stages or where the process might differ for different project structures.

I’ve no doubt that others adopt different processes and I’m happy to carry comments to capture these differences and would appreciate everyone’s feedback.