As others have said, it's at least partly guesswork, though your guesses should be based on (hopefully extensive) previous experience. If you remain totally clueless, but nevertheless interested, offer to do the job on an hourly basis rather than as a fixed price contract. But if you do things right, fixed price can end up much more lucrative (I'd ballpark by a factor of three on average) than hourly. Moreover, even though they end up paying more, clients often end up happier -- they had a known up-front cost.

But one additional thing I can tell you for absolute sure -- no guesswork required. On any non-trivial project, the users/clients/etc are going to change their minds, have new ideas, etc, etc, before you cutover to production.

Some developers get very upset at this absolutely inevitable development. But it's really a good thing. Only a client who's a complete idiot will have no new/changed/etc ideas as he reads functional specs, plays with prototypes, talks to users, just sits and thinks, etc, etc. And all that just helps you eventually deliver a better system.

But clients have to be prepared for the extra delay and cost of their new/changed ideas. Check that they either already are, or else explain the facts of life as gently as possible. I have a gentle saying to introduce such conversations, that I'll share with you here (but don't tell anybody else): it's "TTT" meaning Things Take Time. Cute enough so it's not intimidating (say it with a smile), but helps get the overall point across at the beginning of a discussion.

And during development, when the inevitable changes are requested, the most sensitive discussion is negotiating corresponding contract changes (meaning more money). Clients will inevitably begin by explaining to you how what they're now asking for is actually already in the original contract. About 20% of the time they'll have an arguable point. Make sure you recognize those occasional occasions, and be more than forthcoming when they occur. But about 80% of the time they're blowing smoke (you know where:), and you have to be firm yet friendly -- good client relationships are everything. Everything. Everything. That's why I started this paragraph by emphasizing "the most sensistive discussion". You've got to get paid, but you can't make clients angry about it.

Sometimes the requisite time isn't budgeted for, or blows a deadline, etc. In those cases, and really in all cases, your functional spec should have a section more-or-less titled "Planned Revisions for Release 2.0". Indeed, sometimes stuff you'd planned for Release 1.0 end up in that section.

As others have said, it's at least partly guesswork, though your guesses should be based on (hopefully extensive) previous experience. If you remain totally clueless, but nevertheless interested, offer to do the job on an hourly basis rather than as a fixed price contract. But if you do things right, fixed price can end up much more lucrative (I'd ballpark by a factor of three on average) than hourly. Moreover, even though they end up paying more, clients often end up happier -- they had a known up-front cost.

But one additional thing I can tell you for absolute sure -- no guesswork required. On any non-trivial project, the users/clients/etc are going to change their minds, have new ideas, etc, etc, before you cutover to production.

Some developers get very upset at this absolutely inevitable development. But it's really a good thing. Only a client who's a complete idiot will have no new/changed/etc ideas as he reads functional specs, plays with prototypes, talks to users, just sits and thinks, etc, etc. And all that just helps you eventually deliver a better system. Development is, by its nature, a moving target. Don't be mad, be prepared.

But clients have to be prepared for the extra delay and cost of their new/changed ideas. Check that they either already are, or else explain the facts of life as gently as possible. I have a gentle saying to introduce such conversations, that I'll share with you here (but don't tell anybody else): it's "TTT" meaning Things Take Time. Cute enough so it's not intimidating (say it with a smile), but helps get the overall point across at the beginning of a discussion.

And during development, when the inevitable changes are requested, the most sensitive discussion is negotiating corresponding contract changes (meaning more money). Clients will inevitably begin by explaining to you how what they're now asking for is actually already in the original contract. About 20% of the time they'll have an arguable point. Make sure you recognize those occasional occasions, and be more than forthcoming when they occur. But about 80% of the time they're blowing smoke (you know where:), and you have to be firm yet friendly -- good client relationships are everything. Everything. Everything. That's why I started this paragraph by emphasizing "the most sensistive discussion". You've got to get paid, but you can't make clients angry about it.

Sometimes the requisite time isn't budgeted for, or blows a deadline, etc. In those cases, and really in all cases, your functional spec should have a section more-or-less titled "Planned Revisions for Release 2.0". Indeed, sometimes stuff you'd planned for Release 1.0 end up in that section.