Of course you can deliver on the promise. I have been doing it time after time. You are thinking very much in terms of "doing projects with Scrum based on estimates". Once you think outside those lines things become easier. You don't even have to make the customer understand agile. And I don't know why you think I have to perform a lot of "upfront requirements gathering" either, that doesn't sound agile at all.

Here is a hint. When you forget the word project, and just start to deliver the customer what they want, base the price on your costs rather than any bullshit estimate, continue to collect measurements to update costs, keep your "backlogs" and lead times down to the minimum which is agile anyway, it is no problem at all.

Alright I will explain it. The customer comes and says I would like A and B and C. We say, ok, lets start with A, we will give it to you for a special price. We then invest a very small amount of time breaking A down into "features". This is a bit like story splitting. We know that over the last 12 months our total costs were 2 million, and we delivered 1500 hundred of such "split features". So we have a price per feature of around 1300, lets round it up to 1500. We only need a small margin because those costs aren´t some bullshit hours times rates thing, they are total costs including rent, training, people on maternity leave, coffee , pens and paper, travel for the sales guys, everything. Then we provide our offer listing the features and letting the customer pick and choose. We develop the ones he chooses. He pays. We even allow the customer, once he sees the finished feature, to not accept it! This even happens in around 1-2% of the cases. It means the other features are somewhat subsidised a bit, but thats ok. Contracts can be very lightweight, not much trust is required. If the customer wants a total fixed price for A B and C all at once we can do that too, but we add a bit on to cover the chances that our costs might increase a bit after we fix the price. We are transparent about it and in most cases the customer chooses to do the A first, then the B, because the prices dont change that much.

We have statistics to provide the customer information about how much we expect a feature to take before it is delivered, but we make sure it is not a promise. I would say 9 times out of 10 the feature is delivered earlier than expected, and the customer understands and accepts the 1 time it might be delayed a bit. If the customer is dissapointed in any way with the time it takes or the the amount it costs we are happy to give him his money back and terminate the arrangement. This has never happened. If a certain feature or even collection of features has a due date that it has to be delivered by we can take care of that too with a small extra free. In most cases our prices and delivery forecasts are very very competitive. We are also lucky that our customers tend to want very high value work done too where they would almost be happy to pay 10 times what we charge because the value they get from the software is probably 100 times what we charge. But they are taking the risk on that so they get the rewards. There is never any pressure to work hard to meet deadlines. We always base any predictions on solid measurements. If things start to take longer for some reason we update the predictions going forward.

So no upfront requirements gather done on our side even though the customer might do it. "Incorrect" requirements might be a problem that cause the prices to increase as customers refuse to pay for finished work but we haven´t had this problem. Probably because as you say, we work agile and we try to get a finished product in front of the customer as quick as possible.

I think you are just a bit too stuck on project thinking. I know you can do agile with scrum by slogging through a backlog of fixed scope with fixed price based on estimates and rate cards can be very risky there, but that is very far from the way we work.