Fixed bids aren't so bad. The trick is learning to do really good estimates. Figure out how much information/requirements you need in order to create an estimate, and get that data first. Document what YOU understand the scope of work to be (separately from the provided requirements) and make that the basis for your fixed bid.
Many customers will prefer a higher priced fixed bid, rather than a lower prices hourly based estimate, because they can budget for it (or get budget for it) without worrying about overruns. Many less scrupulous development firms (or people who just can't estimate very well) end up billing well over the initial estimate when doing hourly invoicing, and many customers have been bitten by that before.
In my experience smaller client will be more likely to go for the hourly approach, due to the initial estimate being lower, and feeling like they have more control over the costs during the course of the project. Larger companies almost always work with fixed size budgets approved on a project by project basis, and so having a fixed cost (even if it's potentially higher) is key for their internal budgeting and resourcing. Plus it protects against the overruns hourly project can bring. I've never seen a Fortune 500 outsource a full development project on an hourly basis. It's almost ALWAYS fixed price, just due to how they handle their own budgets.
The trick, imho, to good fixed price cost estimating is to get the best requirements you can up-front, and restate them yourself in your SOW, broken out by task groupings instead of however the client structured them. Clarify any potentially nebulous requirements/tasks yourself, and let the client know if they want to change the way you've filled in the gaps, they can do so, but you will need to submit an addendum to the invoice for any changes they make (unless otherwise agreed upon - i.e. same effort swaps of un-developed areas). Once you have the overall task list figured out, do your internal task breakdown and estimates. Then, pad your estimates out by perhaps 50% (this depends on how good you are at estimating, and how many times you've done task/feature X before).
If I have a task doing something that I haven't done before (i.e. some sort of crazy-cool ajax front-end wizardry (I'm a back-end guy)), I'll pad that out a bit more, since I'm likely to run into a snag or two along the way. If it's something I've done 100 times before (i.e. user registration/login/logout/forgot password flows), I don't need to pad that, since I can estimate that pretty exactly.
Also, don't worry if your padding seems high, or your SOW price seems too high. The client always has the option of doing an hourly approach instead. It's up to them. The more projects like this you do, the better you'll get at estimating, and it becomes second nature.
Many customers will prefer a higher priced fixed bid, rather than a lower prices hourly based estimate, because they can budget for it (or get budget for it) without worrying about overruns. Many less scrupulous development firms (or people who just can't estimate very well) end up billing well over the initial estimate when doing hourly invoicing, and many customers have been bitten by that before.
In my experience smaller client will be more likely to go for the hourly approach, due to the initial estimate being lower, and feeling like they have more control over the costs during the course of the project. Larger companies almost always work with fixed size budgets approved on a project by project basis, and so having a fixed cost (even if it's potentially higher) is key for their internal budgeting and resourcing. Plus it protects against the overruns hourly project can bring. I've never seen a Fortune 500 outsource a full development project on an hourly basis. It's almost ALWAYS fixed price, just due to how they handle their own budgets.
The trick, imho, to good fixed price cost estimating is to get the best requirements you can up-front, and restate them yourself in your SOW, broken out by task groupings instead of however the client structured them. Clarify any potentially nebulous requirements/tasks yourself, and let the client know if they want to change the way you've filled in the gaps, they can do so, but you will need to submit an addendum to the invoice for any changes they make (unless otherwise agreed upon - i.e. same effort swaps of un-developed areas). Once you have the overall task list figured out, do your internal task breakdown and estimates. Then, pad your estimates out by perhaps 50% (this depends on how good you are at estimating, and how many times you've done task/feature X before).
If I have a task doing something that I haven't done before (i.e. some sort of crazy-cool ajax front-end wizardry (I'm a back-end guy)), I'll pad that out a bit more, since I'm likely to run into a snag or two along the way. If it's something I've done 100 times before (i.e. user registration/login/logout/forgot password flows), I don't need to pad that, since I can estimate that pretty exactly.
Also, don't worry if your padding seems high, or your SOW price seems too high. The client always has the option of doing an hourly approach instead. It's up to them. The more projects like this you do, the better you'll get at estimating, and it becomes second nature.