Well, it depends.
First off, let's throw out proprietary code: when I was a consultant to a client, I basically told them, it's a scam. You're binded forever to that particular company and they can ask whatever they want for any kind of modifications for which there is no pre-built functionality, and they can ask for extra for any functionality in the future.
So, option 1 isn't an option. Ever.
We expect option 3 to come with the sourcecode given to the client at the end, otherwise see option 1.
Between option 2 and 3, it depends, what kind of website it is.
Usually, there are three routes:
- grab an open source CMS, and add required functionality in terms of modules
- grab a (usually open source) MVC / MVVM / ... framework and build required modules
- build everything from scratch, leveraging only (mostly open source) libraries.
As you see, here, basically we have a framework appproach problem.
Most open source CMSes will have a content-oriented approach: it's relatively easy to create text content and navigation in them, and you can build modules which are usually record-oriented (so, it's basically a CRUD system with modifiable templates and the framework generates admin interfaces for you). Also, you can grab existing modules which are doing certain tasks, you can grab paywalls, etc.
Think of it as a content system with plugins.
Their disadvantage is, that their programming approach might not fit what you're developing, and also that their interface can be cumbersome. If the customer is actually in need of an application, with only a few static pages, but otherwise no resemblance of an online portal / newspaper, it's just a waste of time, effort, and UX.
With frameworks, you usually build an application, and the administrative interface contains only what the user really needs.
- it's tailored to the user's need from a UI perspective
- it offers less freedom on user configurability (or freedom costs more)
- UI has to be designed from scratch for the administrative interface
(If there's no admin UI, go for it, now :)
And then, there's the custom approach. It offers an enermous code flexibility. If your application isn't a record-based information application, or you have groundbreaking new ideas on how to develop really understandable code which already proven in a pet-project that they're better than MVC / MVVM / MV*, then you might have a go for it.
- Performance (usually such apps are faster)
- More domain-oriented model, so, it's tailored for the user both inside and outside
- Slower development time
- Perhaps noone else could touch it
- All the cons of the MVC solution
So, all in all, it depends on:
- what kind of use cases is it supposed to support
- what kind of complexity is the user able to bear
- how much development effort (or: how much money) is there to finisih it
- how much is vendor lock-in problematic
Usually, the question is between an Open Source CMS or an Open Source MVC framework, and it's nearly never fully custom development, nor is it proprietary.
But again, it depends on usage.