That gets into some interesting points:<p>1. Cost-plus pricing (or contracts).  Here, the vendor (that&#x27;s you) gets costs plus some value.  Which means that the customer probably wants to know what goes into determining those costs.  This in turn requires a close familiarity of both parties.  This was more common say, in the 1970s and earlier, and especially in government major-projects negotiation.  But it&#x27;s why <i>negotiating contracts</i> itself is a substantial activity.<p>If you&#x27;re creating a one-off product, there <i>isn&#x27;t</i> a market price.  There&#x27;s what you and a buyer agree to.  Depending on circumstances, neither of you may be particularly free to walk away and go elsewhere.<p>2. Moen&#x27;s Law of Bicycles:  bad customers make for bad products.  This is almost certainly a variant of Gresham&#x27;s law, itself a generalisation of the point that <i>information sufficient to distinguish product quality</i> is itself difficult to come by.  This manifests in multiple ways:  crap quality cheap products flood markets, or flashy, easily-distinguished, <i>but not materially significant</i> features are added to products.<p>True quality, measurable in the <i>use value</i> of products, is often quite difficult to assess.  This is tightly coupled to the Dunning-Kruger effect.<p>3. Map-terrain relation.  A plan (or contract) is a <i>map</i>, it <i>isn&#x27;t</i> the terrain itself.  In many planning (and legal dispute) instances, there&#x27;s a confusion of these.  A contract which fails to encompass materially relevant information is at risk of being voided.<p>The upshot, again, is that <i>contracts don&#x27;t define software development schedules</i>.  Software development does.<p>It also means that you probably want to desgin the contract scope for developing complex products much as you do those products:  iteratively, over time, with conscious trade-offs of features and costs.<p>Everything else is setting you up for a mismatch of model and frame to reality.  Reality wins.