Thomas, you are right. It is of course important to know the cost of any good thing before you decide on the investment. So what costs are we paying to allow us to deliver at any time?

We have spent time (and therefor money) creating 1) an automated installation program, 2) an automated deployment script, 3) an automated build environment and 4) many automated tests.

The automated build and tests ensures that every release we make have been reasonably verified for high quality. The automated deployment ensures that actually releasing it just takes a few minutes. The automated installation program ensures that the customer is able to put any new release into production himself.

The highest cost is on writing the automated tests and having an automated build environment executing the tests. This cost however is fully covered by the time saved on doing manual tests. That the tests also enable us to deliver at any time is just a valuable biproduct.

The second highest cost is probably the installation program. But this is one of the deliverables of the project, so it would have had to be written anyway. The only cost here that can be attributed to "delivery at any time", is that we wrote the installation program early on and has to maintain it during the project. That cost is actually very small, about ½ percent of the project time.

The final cost is having an automated deployment script, uploading the new installation program to a website. This cost is similarly very small, also about ½ percent of the project time.

So delivery at any time might not be for free, but almost...

I think the only thing really needed for this "always-production-ready" approach to work, is that the software has quality built in from the very beginning. The cost? Personally I think it is insignificant compared to the benefits provided to the customer. You will pay a bit more per feature as you go, but those features will pay back faster, than if you released them in bigger batches. If you don't need a stabilization phase at the end of the project, and can release features as each of them are completed, the customer can start earning/saving money from very early on.

Thomas, you mention that fully updated and complete documentation is very valuable - but costly. From my point of view, only documentation that actually proves to support development speed and quality is valuable - the rest is wasteful. In fact I think you need to write the least possible documentation that will support speed and quality.