Customers don't always provide us with a formal Request for Proposal (RFP), often times we get a great idea written down on on a few sheets of paper or a one paragraph email. While other times we will get a 40-page RFP that provides exacting detail.
Regardless of how the customer conveys their idea, they sometimes only know the "high level" of the how to reach their goal, not the specific details, which (more often then not) is where a larger portion of costs lie. This does not have to be a surprise to the customer. When they hire us, we help them define their idea, and more importantly, what it will take to make it a reality.
A common problem to accurately pricing projects is that proposals happen so early in the process. As the developer, we only have a handful of meetings, phone calls or a document to understand the project. We do our best to come up with a fair and accurate price, but it often feels like a shot in the dark.
What we do to be more accurate? Our company believes in pricing a project for what it costs. Over the years, we have seen situations where a company comes up with a number, then doubles or triples it arbitrarily to pad the rate for unforeseen circumstances. This helps them address the uncertainty about the project by recklessly increasing the cost. This is not how we operate.
When we price a project, we not only price what we know about the project, but also provide feedback on what we don't know. We present worst-case scenarios, risks, and point out all the issues we think could affect meeting the project goals.
When we have to make an assumption, we will point it out. If the presented price is going to get you two comps and two iterations, then we will set that expectation up front. We are not into the "say anything to close the deal" mentality.