That's a tough question that I don't think any of us can answer succinctly.
It really depends. You first need to define the scope of your project. This
should be a general overview of what it will do. Next, you need to write out
all of the tasks required to implement this scope. This requires more fine
detail into exactly what the application will do, what technologies it will
use, etc. While you are creating the tasks, you need to estimate how long it
will take to do. This is dependent on the experience of the developers who
will be implementing the plan. I usually tack on 30%-50% for hubris. Lol.
Once you have your tasks, you need to determine how many of these tasks you
can do simultaneously and how many developers you will be provisioned.
Depending on the number of developers, you need to allocate time for
communication and synchronization. Also include the design phase in which
you will create your basic architecture. The trick is you have to have a
pretty good idea of what architecture you will be using to accurately
estimate your times. Do you have any experts on the frameworks you will be
using? If so, less time, if not, you need to account for learning the
technologies.

You might be in over your head here. Learning how to do this accurately
really takes experience in not only development, but estimating the time it
will take for someone else to do it. The good news is that if your client is
fairly patient, you will get experience by trying, if not, you might be in
trouble. I would definately use a tool like Microsoft Project to implement
your task estimations. It will automatically create Gantt and Pert charts
for you so you can visualize whats going on. The more complex the project,
the more tasks and the easier it will be to get lost if you are just doing
it on paper.