A really effective way of bootstrapping your start-up is to offshore and outsource 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:

• Build a long list of development companies
• NDA all the companies on the long-list
• Issue a Request for Information (RFI)
• Analyse responses and short-list the developers
• Issue a Request for Quotation (RFQ)
• Analyse responses and select a preferred vendor and a spare
• Negotiate contract with preferred vendor
• 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. Regular readers of this series can relax: the whole lot has been written in advance, so there won't be any month long gaps in between!

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. 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:

• 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)
• Experience working with start-ups
• Offices somewhere in the world where you are happy doing business
• 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:

• Use your network: ask anyone you know who works in the software industry for 2-3 development company recommendations
• Use referral companies to provide connections and act as a filter
• Use associations to help pinpoint development companies
• Use tools like eLance, Scriptlance and Rentacoder to find developers
• Use Google to help find companies
• 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; and 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 next week's post I'll detail how to write and issue an RFI; and then short-list your developers.

For a simple system the process outlined in this post 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 - so budget 3 months of full-time work.

A Word on Strategy

Every good business begins with a solid understanding of the proposition and business plan - in short, your strategy. It's 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.

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 your 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 do option 1. Don’t do it - option 2 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

The first thing you need to do is get yourself tooled up is 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 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 be. When you’re building the mock-up, 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.

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

The Functional Specification

This document is the most important document that 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.

The first thing you need to do is get tooled up. Write the document in Word (or an equivalent). You’ll need to include a lot of screenshots - for this I’ve always found the Firefox plug-in Pearl Crescent Page Saver invaluable, because it lets you take screenshots of a whole webpage (not just the part which is displayed). Secondly you need some software to create flow charts in. I used WizFlow before we bought Visio from Microsoft. Wizflow is 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 understand what you are saying. The structure which I always use is:

• Confidentiality notice ‚Äì make it clear that this document is your property and you are serious about controlling your IP
• Introduction ‚Äì you should describe your company, the structure of the document and a one paragraph overview of your system
• 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.
• 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 below).
• End-user functionality ‚Äì a section for each system module (see below) in the system overview. Each section should include several sub-sections for each possible action within that module.
• Administrator functionality ‚Äìsection for each admin module and sub-sections for each possible action.
• 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 the email system used in the mock-up:

In the above simple example, the four boxes are the four major sections within the "End-user functionality" section of the functional specification. Within each section you should cover, with precision, what all of the possible actions are and what the system should do in each case. 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 that 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 seemingly can’t launch a new web site these days without using a few dollops of AJAX here and there. 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.

Container Documents

In parallel to writing your functional spec, start 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 come 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 you maintain a clear mental space free from idea clutter.

Conclusion

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. But 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.

[Ed: Thanks Matt for continuing this insightful series. To see how Matt puts all his theory into practice, check out his own start-up Aroxo. You can sign up for their beta trial using the code "readwriteweb2".]

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 it 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 startup, 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 to plan your release, all the documentation you'll need, and much more.

So, what does it mean to bootstrap a company? Bootstrapping involves launching a business on a low budget. Practically this means that you’ll outsource (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 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.

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. But it is fraught with risks - and the primary risk you need to guard against is software development failure. Two thirds of outsourced projects fail, so there is a high likelihood of failure. The main causes are:

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.

To have the best chance of success, follow this bootstrapping process:

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 that 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 how to think like a developer so that you can communicate with them. 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 in a later post.

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 while you are doing the mock-up and you can easily run 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.

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 will this cost?

It is often said that bootstrapping is cheap. But 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 burnt through $5-7 million before launch.

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

Project complexity is the main driver of cost - i.e. 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. And by doing the development yourself, you’re competing with an offshore company that has specialists in all the skill areas I mentioned above. Plus there's a practical limit to the size of the project you can accomplish.

Should I offshore?

When you consider the question of whether to offshore your development, if you keep things local you’ll save on your travel budget. But if you're in the US for example, then your development cost will be anything from 5-10 times higher than offshoring 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 is much higher if you consider lost earnings during the build.

Conclusion and Key Takeaways

This should give you a good overview of the bootstrapping 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 plenty of examples.

Here now are the key takeaways to this post:

• If you are outsourcing 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 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

Written by Matt Rogers of Aroxo. If you'd like to know more about Aroxo, you can sign-up for their beta trial using the sign-up code “readwrite“.