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.

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.

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

Firstly, some facts sourced from eBay’s quarterly reports:

1. eBay’s subscriber activity rate has declined from 41% in Q1 2005 to 35% in Q2 2007
2. after a few quarters of fast decelerating growth, the number of listings it carries has actually fallen 6% in Q2 2007 (compared to Q2 2006)
3. the average cost of a listing has risen from $1.72 in Q2 2006 to $2.31 Q2 2007 – a 35% rise
4. eBay has announced it is launching a range of user-generated content services (such as blogs and wikis) as well as filling a few proposition gaps by launching services such as Gumtree and “kijiji” in the US market.

The chart below details some of this.

My source data is available here.

Before I go on, an important disclosure

I am a co-founder of Aroxo which will be a major eBay competitor when we launch in October 2007. I’ve sourced all the data above directly from eBay, although I have performed some calculations on these data myself. You can see what I’ve done here.

With that in mind, what follows are my opinions based on what I see happening in the market.

So what’s happening with eBay?

I believe that that eBay’s management thinks that online auctions have reached the limit of their natural growth.

The first clue came when it raised its prices. It only makes sense for a company to do this if it believes the increment in price will offset the reduction in demand, in short it’ll come out earning more money. eBay raised prices because it believed that the drop in listings would be offset by the increase in revenues. Pushing up prices is the way to grow revenue in a flat market. A company which still expects growing demand, doesn’t raise its prices.

The second piece of evidence comes from its eclectic strategy, starting with the expensive and hard to understand Skype acquisition, eBay has embarked on a range of new initiatives including blogs and wikis, launching kijiji in the US and continuing to roll-out Gumtree.

Finally the seemlingly knee-jerk “freeish” listings day which it recently ran and eBay UK’s upcoming half-price listing promotion seem to be an effort to push up listing numbers in response to analyst concerns that its growth is stalling. These initiatives come at a cost to its revenue.

All of this activity leads me to the believe that eBay is attempting to persuade to persuade Wall Street that it still has some growth potential. It appears to be trying to build some “strategic uncertainty” into its business, otherwise Wall Street will value it on lower multiples as it becomes clear that its business has matured.

What does this mean for sellers?

eBay’s rising fees make it more important than ever to optimise listings.

There are a few simple steps which can help sellers. Firstly calculate the total cost of each sales channel in use (this spreadsheet will help you do that), then manage these costs downwards. The following techniques should prove helpful:

1. Use “A/B testing” to improve final values. This involves trying different listing wording, closing times, listing configuration and starting price (etc) on the same (or similar) products to see which achieves the best final values
2. If you have a store, use relevant blogs and forums to drive traffic to it. Note that spam has the opposite impact, so make only relevant and beneficial posts and comments and include your store in your signature, people will find their way there. Use Technorati to find blogs that are relevant to your business
3. Experiment with alternative sales channels (such as Amazon, Google AdWords and for some products types Gumtree and Craigslist) to see if they can help lower costs
4. Use sites such as AuctionBytes and PowerSellersUnite to find alternative sales channels and to keep up-to-date with new launches
5. And finally, the plug. If you sign up for the Aroxo alpha trial and use the sign-up code “alpha”, we’ll give you $20 (£10) of free Aroxo credit when the site goes live. Also, if you’re an active seller on eBay we’d like to invite to the Aroxo Seller Board.

eBay has critical mass in the online auction space, which is why those sellers who’ve tried to either implement a boycott of eBay, or find alternative auction site have run into problems. Without a decent supply of buyers, the lower listing and final value fees still result in a higher average cost for that sales channel (as more items go without bids or without achieving their reserves). Aroxo’s unique business model has been designed so that these problems don’t arise for sellers.

Closing thoughts

It seems clear to me that eBay’s current strategy suggests that they’ve run out of ideas to innovate and drive online commerce. Online retailing continues to grow its share of overall retail sales, and yet eBay’s growth has stalled. They’re losing idea leadership in online person-2-person trading.

eBay is still a good place to trade for many buyers and sellers, but their strength comes from the network effects that are a natural part of the auction process. However, Aroxo’s new sales model will give buyers and sellers a viable alternative which benefits all.

What do you think is happening with eBay? Your comments and thoughts are more than welcome.

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.

My research into Web 2.0 has lead me to take a particular interest in how people are affected by “Web 2.0″, in short, rather than worrying about what it is, or how it is defined, I’ve tried to look at what impact it has on users. I believe that Web 2.0 affects users in 3 ways:

1. Personal expression – It gives users a greater ability to express their personalities to others
2. Efficient connections – It makes meeting new like-minded people more efficient
3. Information discovery – It changes how people discover information

None of these dynamics are new or unique to Web 2.0 – they represent some of the core motivators of most humans – all Web 2.0 has done is make achieving these human objectives online easier.

This is much more than “AJAX and RSS”, and other technologies frequently associated with Web 2.0.

1. Personal expression

Web 2.0 gives people many more option to express themselves. We now have increasingly widespread adoption of capabilities such as blogs, wikis, Q&As (as well as technologies which have been around for much longer, including personal webpages, forums, etc). These enable people to communicate and craft their personalities more effectively. Practically, Web 2.0 style applications frequently make use of:

• Personal icons – From Windows Live Messenger, to the mybloglog link on this webpage, Web 2.0 expression often start with including an image to represent yourself
• Profiles – People now commonly include detailed information about themselves in the form of profiles, publicly available information about their interests and habits. Personal websites such as myspace and facebook extend these “profiles” to the point at which they are one of the core reasons for using the site
• Snippets – It is more acceptable than ever to express only a snippet of information. To add something small to a conversation or stream of thoughts, blogs, Q&As, forums, etc are all ways to achieve this
• Comfort – People are becoming more comfortable at expressing themselves online, the reticence people used to feel has been blown away, with people becoming increasingly happy to share very personal information with the community

All these changes give lessons to entrepreneurs. New propositions under consideration need to ensure that they give users ample opportunity to express their personalities, whether that be through personal icons, chat rooms, their own web-pages, etc.

Applying these effects to corporate email would add in:

1. Simple personal icons which people select and appear in every email sent
2. Give people control over their corporate directory entry, enabling them to include information about what they are an expert it, enabling others to leave comments for them against their directory entry

2. Efficient connections

This is one of the most fascinating areas of development for Web 2.0. We are now forming more relationships with more people at an increasingly faster rate. People actually seem to compete to build networks of friends (e.g. Facebook, Myspace, Bebo, LinkedIn and the rather exciting VisiblePath).

These services demonstrate the importance of enabling people to form connections between each other. Whilst this isn’t particularly new in the context of the web – discussion forums have been popular for years, there is one important change. These personal networks are being structured. Traditionally online forums where people used to meet were effectively like stepping into an enormous room of people and shouting your question out – Web 2.0 now enables people to build networks and therefore filter that communication down to people they know and trust:

Web 2.0 enables users to structure their network – rather than posting to a discussion forum, users can find information out from within their personal network. This does two things: it effectively filters the amount of information they receive, but because their network contains people like themselves, it filters the information leaving data which should only be relevant to them. For entrepreneurs it means we should design our propositions such that:

• Users can find other users on the basis of shared characteristics (be that location, interests, sex, goals, etc)
• Enable users can create structured networks

In applying this to corporate email, we’d make the following changes:

• The mail server would capture the structured network data, enable people to see who they email, and who they email the most (note this is effectively what VisiblePath does).
• Users could then search their networks for subject matter experts within their organisation – breaking down the barriers formed when working in large corporates.

3. Information discovery

Information discovery is an absolutely key area of development for Web 2.0. Traditionally information discovery on the Internet was performed through search, now Web 2.0 has augmented this with:

• The personal network
• Tagging of data
• Social bookmarking
• Trackbacks and cross-linking

Of these, the first – information discovery through your personal network – is a very underexploited area for entrepreneurs. Discovering information through your personal network is like applying a highly effective filter to the massive pool of information on the Internet. Amazon’s “customers which bought this, also bought this” is a prime example of this working. People who we choose to have in our personal networks are by definition like us in some way, and therefore their preferences will be similar – but different enough to be interesting – to act as a powerful filtering system.

In effect, this dynamic enables entrepreneurs to create new propositions which start to release the information which people currently hold in their heads. A service such as WAYN performs this function for travellers.

It is interesting to note that classic social networking sites really only pull together the first two Web 2.0 dynamics. Services such as Facebook, LinkedIn and MySpace do not do much to capture the information which a user has in his or her head and share it with others.

Applying this principle to corporate email gives us:

• Enable mail users to selectively make corporate emails indexable by the server. The mail client would then enable users to search for, say, a prospect’s name and get back a list of other employees in the company who’ve already contacted them.

To summarise

Entrepreneurs wishing find new ways of approaching old propositions can shake up and old school “web 1.0″ businesses easily. To achieve this they need to:

1. enable users to express their personalities through profiles
2. enable users to build structured relationships with others
3. enable users to discover information through the network structured by the system

Taking an existing business and applying these principles gives a unique Web 2.0 proposition which should significantly help drive traction, stickiness, usage and therefore value.

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.

Having been through a vendor selection process which encompassed 32 different companies, some off-shore and some on-shore I’ve seen a massive variation in quality, costs and skills. I found the principle of caveat emptor very relevant.

My key learnings were firstly that off-shoring is not cheap, it is cheaper, but it isn’t cheap. Secondly there is a significant variation in quality which a properly run RFI and RFQ process can help select out. Many of the companies we included in our process I would use again, several I would not.

In my experience, there are two pitfalls to avoid when out-sourcing, both of which a professional client can avoid. Firstly the client must prepare a clear specification of what they want – in order to communicate precisely what needs to be developed across timezones and continents the client needs to know exactly what they want. My understanding from talking to off-shore developers is that they frequently receive little information about what needs to be developed.

Secondly, out-sourcing still requires time on the ground with your development team, all the technology in the world won’t replace the accuracy of face to face communication. In addition careful and close management is necessary – speaking to your developer on a daily basis helps to prevent costly errors.

I am also of the view that, assuming the development company has the basic technical skillset to deliver your project then any failure to deliver will be as much in the hands of the client as the developer.

In the end my company we went with a development partner based in India and so far we’ve been very impressed with their professionalism and skills.

See my LinkedIn profile to link to the full range of answers: http://www.linkedin.com/in/mrogers