It doesn’t have to be a nail biting experience trying to write a good web development proposal. I realized sometimes you can just keep it humble and you’ll still get the message around the bend.

In this article I will make an attempt to give you a guideline on how to get a web development proposal done the way I have been accustomed to.

Before we start, there is on simple rule to follow…

Be true to your self, be honest and get it all down on paper.

Here are the basics to getting things going:

Okay first of all its good to give a brief background history of yourself or your company. At least this helps get some of the mystery about whom you are and it provides a great environment for your client.

The next thing you will want to do is to give an overview of the company you are submitting the proposal to. You may need to do a bit of research on them and try to get quite a bit of understanding about their products, services, target market, goals, company vision and try put these together to come up with an outline – a rough outline of how you will achieve this.

To get things rolling, a diagram will go a long way. You know what they say. A picture is worth a thousand words. To get the flow right with the client, you will need to draw a flow diagram just to illustrate what you are putting forward to the client. This basically should show the navigational structure of the web site.

A flow chart without a description of what it is about is of no value. So you will also need to explain what each element of the flow chart means. A detailed description is the better way to go. Be clear and concise. I am not going to give a tutorial on how to do a flow chart. I believe its out of the scope of this article. Try our external links in the resources page. You will probably find good tutorials on this there.

At this point, it is time to put down a few estimates, which includes time, cost and limitations. Give a breakdown of the production time. Specify how long you will expect to take in each development stage. Be sure to give a realistic time limit and have an allowance for delays. One thing I know is that most times things usually go wrong during development and delays are imminent. If it is in terms of price costing, I know there is also a tendency to quote too close to the bone to try and win the clients favor. This is another bad idea. When things go wrong you will end up making great losses.