First off, you can get better at estimation. Takes time and discipline to collect and analyze your historical information, but, in the long run, this will make you more competitive and profitable. Record the elements of your estimation process for each project. What was the "step," how much effort did you estimate, and what was the corresponding charge? During the development and delivery phase, keep meticulous records of ACTUAL effort and time according to the "steps" of your estimate. After the project, review your projections vs. actuals to figure out where your estimations were good and bad. Pay special attention to the "bad" estimates and answer honestly, "WHY?" It ain't the most fun you can have, but it will make you a better estimator. There are web resources that provide statistical discussions for how to improve your estimation processs; if you're interested, a jumping off point might be:
You can simplify your estimation process and reduce your actual costs by amassing libraries of standardized tools and code. These libraries can be Open Source or your own. Each time you solve a problem, either solve a more abstract, general case and apply that solution to the specific case for your project, or, if time doesn't permit that, earmark the code to be revisited for abstraction during some later interval of down-time. This will provide you a growing collection of recyclable "widgets" and patterns. Think components.
Use standard development tools and perfect your grasp of how they work. For instance, Eclipse with the Aptana (web) and Subversion (version control) plug-ins can save you a huge amount of time in development, debugging, and recovery from mistakes. The more time you invest in learning these tools, the less time you spend developing new code.
As for cross-browser silliness, identify right off the bat which browsers you MUST support. Not all clients require support of all browsers (I have know customers who actually give messages to visitors who don't use "the blessed browser" that the customer ONLY provides reliable web-services to whichever is the "the blessed browser" - can you imagine!!). Once you know which browsers are to be supported, pick a strong document type, e.g., XHTML 1.0 Strict, and do all of your initial development in the most standards-compliant one. Work your way down the list of browsers in the order of increasing deviance from standards, repairing the functionality and appearance for each. For instance, I start in Firefox, move to IE7, then IE6, and then everything else (if there are more on the list). My model provides the additional value that I can use IE condidtional comments to add markup, styles, and scripts for the "Evil Empire" that Firefox, et al., simply ignore. Keep good records and links to online resources that detail the KNOWN cross-browser issues, so that you don't re-invent solutions. The more you can "widget-ize" and recycle, the better (less hair-pulling, lower costs to customers, more correct and competitive quotes). I also use VMWare for the sole purpose of being able to run a bunch of different browsers on the same box. Makes it much easier to flip back and forth among VMs as I'm tweaking the app across different browsers (oh, if only I had a Mac VM!).
Before providing the estimate, determine whether your customer lives in the land of "must have a flat-fee" (more risk to you, but greater profit opportunity, if you get good at estimation) or "will pay hourly" (less risk to you, but better chance for lower cost to client, if you estimate well). Give estimates in both fashions; that is, give a task-based estimate for how many hours (scaled for uncertainty) of what and for how much, reporting what you expect. Explain the risk difference - "pay me hourly, and I stop charging you as soon as I'm done" - "pay a flat-rate, and you may pay more than needed, but you insure against against cost overruns." Make sure that your flat-rate EXTRA-covers your expected costs scaled up for uncertainty. The more uncertainty about the tasks, the higher the risk multipliers. For new (to you) technologies or techniques use a factor like ?0 to scale up your estimate. The more familiar the work, the less uncertain you should be of your estimation skill and the correspondingly lower your "fudge-factor."
Determine whether the word "estimate" is being used correctly, i.e., are you really just providing "THE PRICE," or can the amount be subject to change in light of development challenges? If it's "THE PRICE," scale upwards to cover your increased risk.
If you're going to employ other developers, scale their estimates up so that you are likely to show a profit on their work. You are serving to manage them - your time as a project manager ain't free either...usually, about 20-30?hould cover your efforts.
Finally, make sure the customer understands that any changes to requirements after the project begins invalidate the estimate. If they add, change or delete features, the estimate must be altered to accommodate those changes. Re-estimate in light of change, and get sign-off on the new estimate before continuing.
Lots (the majority?) of clients prefer flat-rates, because they know how much they have to spend. They will accept your flat-rate estimate in preference to an hourly, variable rate, since know they can afford the cost (and won't have to explain to their bosses why the project ran over the estimated cost). Properly managed, this is an opportunity for you to make MORE profit, but you must hone your estimation skills for this to become the case.
Short answer is, flat-rate is fine, if you manage it properly, but don't set yourself up to earn $2/hr by giving a very poor, low estimate.