Alas if we can’t build it ourselves, or get a reasonably priced solution (less than £10k to implement) then it’s a no-go.

I understand it’s complex and needs a good design phase but I think many people would rather save costs and adapt their working practices and outputs upfront, get an “off the shelf” product, and worry about changes later. Just my opinion, but it’s much easier to ‘creep’ purchases than get a lot of upfront spend.

But maybe, with the value of information being realised more and more in organisations, that is changing?

It seems to me you were asking the wrong question. Until half way through this post I was going to suggest “Why no customise rather than build”, but by the end it seems clear you’re not asking for an “authoring tool” at all, you’re looking for a client-side filtering and personalisation tool. That’s not authoring, it’s assembly.

One of the major objectives of component content methodologies is to allow the kind of dynamic delivery you’re talking about, but it’s delivery, not authoring. They’re not creating the content, they’re filtering and personalise it into new deliverables according to their needs.

The XML paradigm is that content is separate from the publishing and delivery later. That’s (somewhat) contrary to the HAT, DTP and (older) FrameMaker model at a fundamental level so tools are either designed to be “one stop shops” and you accept that no tool will be all things to all men, or you separate authoring and publishing as you do in XML/DITA.

I agree, there are not a lot “off the shelf” dynamic publishing options at the moment for anything. We usually have a requirements and design phase for each client and we implement something based on our codebase with some variations each time.