Customers don't need to know the cost, they need to know the price. The most important factor in determining that should be the value of the software to the customer, not the time it will take to produce it.
1. Cost-plus pricing (or contracts). Here, the vendor (that'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's why negotiating contracts itself is a substantial activity.
If you're creating a one-off product, there isn't a market price. There's what you and a buyer agree to. Depending on circumstances, neither of you may be particularly free to walk away and go elsewhere.
2. Moen's Law of Bicycles: bad customers make for bad products. This is almost certainly a variant of Gresham's law, itself a generalisation of the point that information sufficient to distinguish product quality is itself difficult to come by. This manifests in multiple ways: crap quality cheap products flood markets, or flashy, easily-distinguished, but not materially significant features are added to products.
True quality, measurable in the use value of products, is often quite difficult to assess. This is tightly coupled to the Dunning-Kruger effect.
3. Map-terrain relation. A plan (or contract) is a map, it isn't the terrain itself. In many planning (and legal dispute) instances, there's a confusion of these. A contract which fails to encompass materially relevant information is at risk of being voided.
The upshot, again, is that contracts don't define software development schedules. Software development does.
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.
Everything else is setting you up for a mismatch of model and frame to reality. Reality wins.
Let's say they figure out you only spent 100 hours to deliver them $50,000 of value. It's your job to persuade them that that guy on the internet who says they would sell them 100 hours of dev time for just $5,000 will only give them $5,000 of value (if that). If I have a choice between getting someone who delivers value at a rate of $500/hour versus someone who delivers value at $50/hour, and I need $50,000-worth of software, I should choose the more efficient developer, not the cheapest one.
For the kinds of projects my company tends to do, when we're getting into repeat business we're generally not competing with other contractors. Our clients know that the other contractors would have a ramp-up cost that we don't, and an unknown working relationship vs our good working relationship. Instead, they look for per-hour discounts and ways to 'cut costs' while delivering the same value. They also typically have their own development team who don't get paid nearly as much per-hour as my company charges, so they look to share more of the work with their internal team. Since we do product, services, and support, including training, it's hard to argue that the internal team can't or shouldn't do the work.
It gets complicated, but in the end we mostly come out alright. Our clients are well aware that taking on additional work reduces our likely development cost but increases overhead costs and raises project/schedule risks. It's a tradeoff they accept, and we work with them to ensure the project is successful.
My point is, in the real world you can't just charge by the value you provide rather than by the cost of providing that value. That's a simplistic point of view.
I do appreciate that the reality is that development contracts work that way. I've just spent a lot of time being frustrated at how often the business conversation around software assumes a basic hourly contract cost-plus basis.
I have no problem telling a customer that something along the same lines as a previous project will be more expensive today, because it was initially underestimated and I ate the additional cost. They realize they got a bargain the first time, and I don't have to eat the same costs to keep the customer. Of course, starting from the first project, I work very hard on building a trustful relationship to support such a claim.
1. Cost-plus pricing (or contracts). Here, the vendor (that'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's why negotiating contracts itself is a substantial activity.
If you're creating a one-off product, there isn't a market price. There's what you and a buyer agree to. Depending on circumstances, neither of you may be particularly free to walk away and go elsewhere.
2. Moen's Law of Bicycles: bad customers make for bad products. This is almost certainly a variant of Gresham's law, itself a generalisation of the point that information sufficient to distinguish product quality is itself difficult to come by. This manifests in multiple ways: crap quality cheap products flood markets, or flashy, easily-distinguished, but not materially significant features are added to products.
True quality, measurable in the use value of products, is often quite difficult to assess. This is tightly coupled to the Dunning-Kruger effect.
3. Map-terrain relation. A plan (or contract) is a map, it isn't the terrain itself. In many planning (and legal dispute) instances, there's a confusion of these. A contract which fails to encompass materially relevant information is at risk of being voided.
The upshot, again, is that contracts don't define software development schedules. Software development does.
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.
Everything else is setting you up for a mismatch of model and frame to reality. Reality wins.