SharePoint OOTB features Vs Custom Developement

Ok, I always ask this question to m开发者_运维问答yself.

When it comes to SharePoint OOTB features VS C# custom development, where exactly do you draw the line?

Just post your thoughts... (even if you think this question is ridiculous :-P)

---

I can't recall one single project where SP "OOTB"...

1. Fulfilled the client requirements entirely (except for the most trivial cases). In the case of changing requirements this often led to over-complicated hacks or eventual re-write as some "custom development".
2. SharePoint Designer didn't make the problem harder and less maintainable. Worst. Product. Ever.

Edit: Actually, now that I am "forcing" myself to remember it, I think it all devolved to some hack or issue avoidance to get around some limitation or another. The difference is where the hack is encountered and how easy it is to perform said counter-measure(s).

---

Not sure how you're going to get anything like a specific answer to this, shouldn't it be decided on a case by case basis?

Surely its just "If the cost of the custom development is less than the cost of 'living with it as is" then develop, or not?

---

In SharePoint there are many customizations that can be done without having to develop (if you are referring to 'custom development' as C# code. Several thing can be done using Sharepoint Designer, and I wouldn't know if those are to be considered custom development..... I have created websites out of VS, changing basic stuff with Designer, and I've created workflows with WSS as the UI... so it also depend on what you want to accomplish...