Problem is, as always, the degree of abstraction. You -can- write a rendering pipeline with awesome effects that is very closed (efficient and very well coded for the particular tasks, but hard to extend) and you can write the same rendering pipeline with the same effects but modular and open. This can result, though, into slightly inefficiencies if it is not well written. So, the design of the framework is the most interesing aspect in such an attempt.

So, lets face it: I am actually going to write me my own rendering pipeline for my next game. I will do it like this: I will write down what effects I -really- need and what not and what quality and what techniques I will use. Then, the whole architecture and wiring will be sketched on paper. After everything is thought through, I'll do a straight implementation. Thats it. I get what I need for no additional costs (hopefully ).

If you write a general purpose rendering pipeline instead, you always have to ask "what does the user possibly want to do?". Answers to these questions are broad and sometimes hard to find. Consider, that the rendering requirements of a game like Crysis are totally different to what you have to do for a game like Portal or Age of Empires 3. Plus, sometimes users don't want an effect and disabling it should release some resource of course. E.g. if you don't want to use DOF, you should'nt allocate the render targets for them and you shouldn't compile shaders for them and so on. If you e.g. also don't have any postprocessing effects enabled that need a depth view, then you should'nt render the scene again for it. And what if the user has much vegetation and uses e.g. alpha-to-coverage - how is this treated in the depth view and how is it treated if the user disables this and uses only cutout (binary) alpha??? And what happens if I disable certain features and could put two MRTs into one, just because that the disabling disabled 2 outputs in the first MRT and 3 in the second? How is this treated, is this treated, should it be treated??? These are just basic questions, but very hard to answers, let alone that somehow has to code it.

It is very hard to create a rendering pipeline like this. That is why each (good) game uses it's own pipeline.

So, if we ask each user "what do you basically need for a game" and the user is honest and doesn't add things he saw in a latest tech demo or something, we will get a HUGE list of things which might be compilable into one unified rendering pipeline - or not. Well, I guess the latter.

[EDIT]

The estimation from Slin, btw, is, as he said, relatively free and totally depends on what you need. But you can count 10-20 Eur as standard price per hour. It just depends on the complexity of the task and the versatility you need, as I said.