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.

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.

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.

Over-the-shoulder tests

This test phase is the most fascinating for the founders, as you get to watch people actually interacting with your system. This test should be done independently, as those close to the system are inclined to guide the user towards positive responses, rather than getting genuine feedback.

But if you are bootstrapping or operating on a tight budget, you may well be doing it. So, here’s what you do:

1. Write out a list of scenarios or tasks which you are going to as people to do
2. Find 5-15 people who represent your expected customer base
3. Sit them in front of a machine and get going

Your first task should be to get them to look at the homepage for a few seconds (no more than 30 seconds), then ask them what they think the site does. People should find it easy to understand the site from the homepage. If not, probe a little to find out what you can change to make it clearer. Then get started on the scenarios.

Your job is to generally keep quiet and take notes as they use the system. You are particularly looking for times when something confuses them, you may notice the person lean forward and start to look confused. At these points feel free to interrupt and probe, ask them what they are looking for and what’s missing.

When probing, be very careful to use words like “what” (open) rather than “why” (implies fault). Try not to reveal any emotion, you’re not asking people to tell you how great your system is, you’re after honest feedback. Therefore it is also important not to make people think they are stupid for not being able to use the system, frame it as “we want to get some open and honest feedback”.

Expect some excellent and easy improvements to come out of this to really make the system substantially easier to use.

Task-driven testing

Task-driven is quite different. For a start, you won’t actually be watching people, they’ll be running through tasks on their own. This is particularly interesting because for the first time people will be using the system without anyone to ask for help. This means you can get more people involved.

To perform this sort of testing there are a few things you need:

1. around 20 particpants to start with (expect about half to actually use it and 2-3 who give you really good feedback)
2. a well defined list of tasks for them to perform
3. a way to communicate the tasks to them and
4. a way for them to communicate their findings back to you.

As you push these changes through to the alpha platform you should start adding more and more people onto the trial. You want fresh eyes to test your UI improvements, people who’ve already seen it, won’t test it as well, if at all.

Your objective here is the test how well the system performs with a small number of people performing defined tasks, so each task you ask people to do should come with some prompts to help them give you relevant feedback.

Goal-driven testing

Goal-driven testing differs from task-driven testing in two ways. Firstly there are a lot more people involved in the trial, and secondly instead of having tasks which people have to perform on the system (e.g Register on the site). You set wide goals for the participants. In context of Aroxo this is something like “buy something” or “sell something” the UI and the website itself should then guide the users through the system, rather than the tasks.

Start your goal-driven testing when you’ve reached the point that you believe the UI of the system is strong enough that people know what they should be doing and how to use the system.

Beta testing

Beta testing isn’t really testing in the same way as the alpha testing which you’ve already performed is. You want a large number of people get see the system and many of them will have registered on your site to do it, so you don’t know them.

This makes beta testing public. If it is public, it’s part of your marketing. Therefore it is essential that it shows your site running well and easy to use. What you may get is some useful learnings about how the system scales, or you may also be able to learn something from some clickstream work.

However, what is most important about beta testing is that it should not be part of your functional and UI testing, it is too late to make any significant changes to the system as you’ll be moving towards a full launch within weeks of starting your beta.

Closing thoughts

One thing which I’ve not discussed in this article is the emotional impact which testing has on the founders. If you’ve been careful with your IP whilst you’ve been building your system it’ll be the first time which you’ve had large numbers of people looking at your system. This means you are going to get a lot of feedback.

It is important not to take this feedback personally. It should help make the system stronger.

You need to remember that you are asking people to look at your system and tell you the flaws and problems with it. You are not asking them to look at it and tell you how clever it is! This means you are going to get a lot of (hopefully) constructive criticism. You need to take this on the nose and think of creative ways to improve the system.

Finally, in the case of Aroxo something which we learned is that it just isn’t possible to test the UI of your own stuff: you are way too close to it. So it is important to have lots of fresh eyes to test each new release.

Good luck!

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.

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.

A word on strategy

Every good business begins with a solid understanding of the proposition and business plan, in short, your strategy. There’s plenty of quality material on the Internet which covers this, so I’ve assumed that you’ve already done this and you’re now want to take the next step.

However, it is worth reading Guy Kawasaki’s 10/20/30 Rule of Powerpoint it’ll provide you with an idea of what should be included in your business plan and strategy. Your actual business plan should be in a lot more detail than Guy describes in his post – his rules relate only to how the results of your work should be presented, not how the content should be derived.

From here, we can work on how to get your system developed.

From strategy to development

Whether you are out-sourcing or developing in house there are two ways to build a system:

1. Give your developers a rough idea of what to build and keep iterating the design as they build it
2. Give you developers detailed documentation of what to build

When out-sourcing, the second option is always cheaper, faster and lower-risk, not only that but the end product will be better architected, more coherent and easier to maintain. Given this, it might surprise you to learn that the VAST majority of out-sourced developments go down route 1.

Don’t do it, it is more work at the start but entirely worth it.

The basic premise of option 2 is simple, instead of relying on your developers to think through your business properly, you take responsibility yourself. You’ll do this in two ways, firstly by creating a mock-up and then by documenting that mock-up in a functional specification.

Your mock-up

First thing you need to do is get yourself tooled up to create your mock-up.

This requires a visual web-editor (assuming you’re building a web-application). Personally I use Visual Web-Developer from Microsoft, it’s free and powerful. However, it is also very complicated to use as it’s a full web-development environment. If you don’t know how to code in C# then it is probably easier and faster to use Dreamweaver, Frontpage or the freeware KompoZer.

A mock-up is a run through of your site and the learning process you’ll go through as you create it will be exceptionally revealing. It sounds simple but when you start to put pen to paper you’ll very quickly find that it isn’t. Your mock-up is the first stage of building a real understanding of what your system has to do.

The mock-up should contain no functionality and doesn’t need the final graphic design. Its objective is to help your developers understand what information the system should capture, when it should be displayed and what it should do with it when the user “does stuff” on your site.

To give you an idea of how it should look and feel, I’ve created a small mock-up of an email service for you to peruse. Granted it is a mock-up for a terrible email service, but it should serve the purpose of detailing what a mock-up should contact.

When you’re building it, remember to include an admin interface – believe it or not, it is easy to forget to include this. Make sure you think through how you will administer the system, handle customer queries, examine user accounts, run reports on user numbers and website traffic, etc, etc.

Only when you’ve completed your mock-up and been through several iterations with any other business partners you are ready to move onto the next stage, documenting it in a functional specification

The functional specification

This document is the most important document which you’ll write for your business. It will tell the developer exactly what your system should do. It will contain every page you’ve created in your mock-up and for each screenshot it’ll explain what’s happening on the screen, what the user can do from there and what the system should be doing in the background. The document is called a “functional” specification because it should describe “what” your system does, rather than “how” it should be done.

First thing you need to do is get tooled up. You’ll write the document in Word (or equivalent). You’ll need to include a lot of screenshots and I’ve always found the Firefox plug-in Pearl Crescent Page Saver invaluable – it lets you take screenshots of a whole webpage (not just the part which is displayed).

Secondly you’ll find that you need some software to create flow charts in, I used WizFlow before we bought Visio from Microsoft. Wizflow if easy to use and does most of the stuff you’ll need.

When you set out to write your functional spec, you need to follow a clear structure so that your developers can understand what you are saying. The structure which I always use is:

1. Confidentiality notice – make it clear that this document is your property and you are serious about controlling your IP
2. Introduction – you should describe your company, the structure of the document and a one paragraph of overview of your system
3. User scenarios – Include at least 5 clearly written accounts of what a user might do on your system. These serve to ensure that everyone who ends up on the development team knows what the system is for, write them as a chronological story
4. Overview of the system –five page description of what you system should do, keep it very high-level and include a system overview diagram (see later)
5. End-user functionality – a section for each system module (see later) in the system overview. Each section should include several sub-sections for each possible action within that module
6. Administrator functionality –section for each admin module and sub-sections for each possible action
7. Non-functional requirements – design integration, SEO, availability and uptime requirements, scalability requirements and load calculation, data validators, security and back-up and the development platform (if you have one)

Clearly in a blog post I cannot cover each of these in detail, but one element which is particularly important is your system overview diagram, whilst the developers might not build the system in this way, it is useful for you to mentally split your system up into modules. I’ve done a simple example using email system used in the mock-up:

The four boxes would be the four major sections within the “End-user functionality” section of your functional specification. Within each section you should cover with precision what all the possible actions are and what the system should do. From this it is easy to build out your document structure. So for “user access” we’d need a sub-section on “Create account”, “Log in”, “Forgot password”, etc.

Start by building out the document structure. Only when that is complete should you start filling out all the details. This way you’ll slowly build up your document without feeling overwhelmed by it. When you are writing one section, you’ll get ideas for other sections – when this happens go to the relevant section and add the thought in square brackets so you know what to cover when you get to it.

Trust me on this: only one person can author a functional specification. More than one person can review it, but only one person can author.

A word on AJAX

You can’t launch a new site these days without using a few dollops of AJAX here and there, it just wouldn’t do. However, you can’t incorporate AJAX into your mock-up (as there’s no functionality). Where there is a functional requirement for AJAX you’ll need to use a new page in your mock-up (the complete opposite of what AJAX gives you). Therefore you need to explicitly include your AJAX requirements in your functional spec, personally I insert my AJAX requirements in a box, so they are clear to the developers.

In parallel to writing your functional spec, start up the following container documents:

• Future ideas for the development of the system
• Legal points you want to make sure that are included in the terms and conditions
• Any design thoughts (include here screenshots of website designs you like)
• Patent ideas
• Marketing ideas

As you are working through your functional spec you’ll be coming up with lots of ideas in all of these categories (and possible more). Make sure you’ve got simple lists you can just drop them into – get them out of your head and into the computer as fast as you can so that you can maintain a clear mental space free from idea clutter.

Creating a quality functional specification is a time-consuming, but essential, job. Take your time and do a quality job. Don’t be surprised if the document ends up being hundreds of pages long. It vastly increases your chance of delivery.

In the next post I’ll be looking at how to build a long-list of developers, run an RFI to create a developer short-list, run an RFQ to select a vendor and a spare and then what to look out for in the development contract.

I’ve covered a lot of ground in this post, and it’s always hard to compress everything necessary into a small enough package to fit in a blog post, I hope you’ve found this useful. If you have, feel free sign up for our beta trial using the code “startup”.

Matt Rogers.

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.

The Aroxo plug

I’ll use Aroxo as my primary reference for how to run the process so it is useful if you know a little about it.

Aroxo is a person-to-person trading exchange for consumer electronics, computer gear, whitegoods, and more. It uses new way to match buyers and sellers that has several benefits over auctions and fixed price sales models. Interestingly it isn’t constrained by the critical mass of other marketplaces – you cannot compete with an existing auction with another auction, no matter what your marketing budget, hence we’ve got a different model which is currently under-wraps.

Marketplaces are inherently complicated systems to build, with lots of workflow which needs building and testing. Especially in our case where we’ve built something which hasn’t been done in the consumer space before. If you’d like to know more may I suggest you sign-up for our beta trial using the sign-up code “bootstrap“.

At 400,00 lines of code, we’ve been up a steep learning curve whilst we’ve bootstrapped Aroxo and we’re passing on the benefits of our learnings here.

What is bootstrapping?

So, what does it mean to bootstrap a company? Bootstrapping involves launching a business on a low budget. Practically this means that you’ll out-source (most likely off-shore) your design and development, you’ll rent your servers, you won’t have an office and you’ll have no salary. Prior to launch, the only expensive professional services which you’ll buy will be your legal advice and accountancy services. Everything else, you’ll have to pick up yourself and learn as you go along.

Why bootstrap? There are a couple of good reasons a company should consider bootstrapping its market entry. The founders may believe that they are onto such a good idea that they don’t want to give up any equity. Or the founders have taken on a small amount of seed financing, just enough to get them into the market. Either way, bootstrapping is a viable model.

There one very bad reason to bootstrap and a major pitfall to be avoided. If no-one would give you any money to build your business, but you’re still convinced you’ve got a great idea then for the sake of my conscience, please think long and hard before spending any money or giving up a source of income. The information I’ll impart here will give you some clear instructions for launching a business, make sure it’s a good way to spend your money before you do.

OK, intros over. On with how to do it.

Overview of the bootstrapping process

I’m starting this series of weekly posts with an overview of the whole process. In the upcoming posts I’ll go into much more detail about each one.

Bootstrapping is a potentially very exciting prospect to an entrepreneur. It enables you get keep a much greater slice of the equity, getting you in to the market so you can raise financing (if you’re going to need it) with a trading history in hand, rather than some PowerPoint. But as I said before, it is fraught with risks and the primary risk which you need to guard against is the failure of the developer to deliver. Two thirds of out-sourced projects fail, whilst this varies from developer to developer, there is a high likelihood of failure – especially when you consider the general start-up failure rate.

Much of the process which I’ll outline is designed to prevent this from happening, so it is worth understanding the main causes:

1. Client fails to precisely express their requirements to the vendor
2. Client continuously changes their mind during the development process
3. A poorly constructed development contract

I could go into detail here with some warning signs and observations about these, but if you faithfully follow the process which I’ll describe here, then you’ve done much to protect yourself.

With this in mind, the bootstrapping process is as follows:

1. Strategy – build your idea into a documented strategy, write down the market you want to serve, what is wrong with how it is currently being served and how you are going to fix it, also think pointedly about how you are going to get the word out to your potential users, where they are online and how you’ll approach them. Test that your idea makes sense
2. Mock-up – build a mock-up of the system you want, each screen in the mock-up must contain the information and navigation you want the final system to contain, you’ll need several goes to get this right, it is not simple
3. Functional Specification – write a document called a functional specification, this explains to the developer what each screen in your mock-up does and what every button and link on the mock-up should do
4. Vendor long-list – build a “long-list” of possible software vendors and NDA them all, but don’t rely on it (more on this later)
5. Request of Information – Write and run an RFI process to sift your long-list of vendors down to a short-list of between 4 – 10 vendors
6. Request for Quotation – Write and run an RFQ process to determine approach, costs, timescales and conditions under which each vendor would deliver, select a preferred vendor and a spare in case of any problems during contract negotiations
7. Award contract – Negotiate a software development contract. There are some essentials to ensure that you’ve got covered, which I’ll go through
8. First trip – if you’ve off-shored then you’ll need to go over there and see the developers to get them started, take them through the entire mock-up and all the documentation, to ensure that they know how the system hangs together. Building a real face-to-face relationship with your developers is not only immensely valuable for you, but also for them too
9. Managing the development – running the development as a client has many responsibilities, you’ll need to know how to deal with delays, systems problems and you’ll need to know how to think like a developer so you can communicate with them. You also need to know when you’ll need to be out there. During this phase you’ll need to be there for the developers to answer all their detailed queries which they’ll have as they start to architect and design the system
10. Alpha, Beta, launch - Aroxo is currently in the process of recruiting beta testers (feel free to sign up using the sign-up code “readwrite”). Getting a large number of triallists and acting on their feedback is essential to building a strong business and having a successful launch, I’ll go through the best way to achieve this

Clearly, whilst I’ve presented this list linearly, it is entirely possible to parallel run some components, e.g. you can start building up a vendor long-list whilst you are doing the mock-up and you can easily be running your RFI and RFQ process when writing your functional specification. But each stage needs to be completed if you are to reasonably expect a quality product by the time the process delivers.

Running through a process such as this is what it means to be an “entrepreneur”, so I’ll be going through each of these stages in plenty of detail in the coming posts.

How much does might this cost?

It is often said that bootstrapping is cheap, and whilst it is certainly cheaper, it is not cheap. Producing a professional and slick product costs money. Our development was a particularly complicated build requiring 5 developers, a systems architect, an html coder, a SQL specialist, 4 testers, 2 designers, a graphic designer, a project manager and a security specialist. If our aim was to raise financing and employ these people directly we’d have burned through $5-7 million before launch. So yes, it is considerably cheaper, but it is not cheap.

With that in mind a rough budget which should be sufficient to bring a system of reasonable complexity to market would be (note that this doesn’t consider any marketing or PR spend):

Project complexity is the main driver of cost, delivery risk and timescale, therefore it is exceptionally hard to be accurate with this, but you are in for a minimum spend of $50k, systems as complex as a trading exchange will involve much bigger numbers. If you have less than this, then you’ll have to do the development yourself, nothing else is going to shift the needle. By doing the development yourself you’re competing with an off-shore company which has specialists in all the skill areas I mentioned above, and there’s a practical limit to the size of the project you can accomplish.

When you consider the question of whether to off-shore your development, if you keep things local, you’ll save on your travel budget, but you development cost will be anything from 5-10 times higher than off-shoring to India or Eastern Europe.

Similarly you’ll need at least one fulltime founder during the development phase to handle the developers and manage any other business development issues which arise during set-up. You’ll notice that there is no budget above for any salary for this individual, so the real cost much higher if you consider lost earnings during the build.

This should give you a good overview of the boot-strapping process, in my next post I’ll outline how to document your requirements in a “functional specification”, how to build a mock-up of the service using free development tools and how to structure your strategy. And I’ll be giving away plenty of examples.

Key takeaways

• If you are out-sourcing design and development, then you’ll want a budget of around USD 50k – 100k, more if you’re developing a complex solution. Anything less and you’ll need to develop the system yourself
• You are not going to be able to manage professional developers part-time
• You absolutely must thoroughly think through how to implement your idea
• Be 100% sure that you have the drive and finances in place to see it through to delivery

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.

I use three simple strategies for generating ideas: 

1. The concept transplant
2. Amplify the essence
3. The inhibitor remover

Each overlaps with the others, all are interrelated, all of them seem to work. I look at each one in more detail below, then I talk about how I use them to generate new ideas.

It is important to note that at their root all of these strategies rely on an idea which is already working. Why take the risk of trying something which hasn’t already been proved?

1. The concept transplant

The first strategy is exceptionally simple. Take an idea which works well, and apply it somewhere it’s not being applied. Making sure that you are not stepping on any patent toes and adding in your unique twist gives you your new proposition.

Social networking, for example, is nothing remotely new. People have been networking socially since the birth of man, people were even using the Internet to socialise and form networks, long before anything like “Web 2.0” was even considered.

The Facebooks and My Spaces of this world just took something which was already happening and did it online. eBay, took the concept of auctions and put them on the web. Guy Kawasaki’s start-up Truemours, just took the human desire to gossip about rumours and put it on the web. Aroxo – my own start-up – takes its base concept from the “physical” world, and applies it to the web. We are by no means out of ideas.

2. Amplify the essence

This is my personal favourite. This strategy helps us isolate surfacing human trends and needs. It requires that we look at something which is working, isolate the human need which is driving it and the amplify it. My Web 2.0 blog post attempts to do this for Web 2.0. Take something which is working well and isolate the core human drivers which sit beneath its success.

Starbucks, for instance, isn’t popular because it sells coffee. It’s still number 1 because no-one has quite captured its essence. Starbucks is a moment of solace, an air of sophistication, it’s a break from the storm in a crazy world. It is also excellent execution.

Apple’s success comes from its positioning of the computer as an expression (even extension) of its owner’s personality and from making computers easy-to-use.

3. The inhibitor remover

Here were looking for what is stopping something from working, typically in another medium, then we find a way to remove that inhibitor. Essentially, ideas which should take off, but hasn’t.

Instant messaging on mobiles hasn’t taken off in Europe. Why? Because people think its expensive being online all the time. And yet in most countries, it isn’t. An easy fix.

Video content on your computer (Joost, et al) hasn’t taken off. Why? Not because of a lack of content, but because being at a computer is not relaxation time, it’s active. But people consume television style content (as opposed to short YouTube clips) whilst sitting comfortably on a sofa.

The final step – applying the strategies

It is easy to trace successful business ideas back to an earlier Idea Genesis using these techniques, but knowing this doesn’t create potential Google beating ideas on a daily basis, that requires an application of the strategies. And this requires a few more steps:

1. an understanding of where you want to apply the idea (e.g. online targetting seniors, mobile/cellular targetting youth/how to beat Google, the next eBay) 
2. knowledge of these strategies
3. exposure to plenty of completely unrelated, but successful ideas and business models

In the Google situation, I started from the premise that nothing lasts for ever, just as with Aroxo we’re setting our sights on eBay, for Google there will be a better way performing search. Then I’ll make sure that I’ve got a good understanding of the 3 strategies above by reviewing them in my mind a few times.

Finally, as I spend my time during the day, I’m constantly looking a how something is done and try to apply it using the strategies to my area of interest. Before you know it you’re finding ideas cropping up regularly.

I do this as a constant day-to-day process and maintain a list of potential ideas which I add to often. I find it useful as I walk around to evaluating and conceptualise the ideas I see around me, thinking how else and where else they could be applied.

These strategies can yield a lot of ideas, but not all of them are going to be brilliant brainwaves. Which means we need a way of sifting out the false positives which involves turning a rough idea into a worked-through proposition. And that’s the next post.

As ever comments encouraged!

Got this far? Sign up for the Aroxo beta trial, if you use the sign-up code “blog4″ we’ll chuck in $5.00 free credit when we launch in October.