If you want someone to build you a website, don't let them build you a bespoke CMS to help you manage it. I've fallen prey to this very temptation, although in my defence it was as much an investigation into technology and the structure of my own content as a solution to the problem of managing said content. But after having spent two years struggling in vain---completely and utterly, to the point of not merely writing zero new code but also writing much less content---I've moved to Drupal. Since doing so I've been playing with blocked-out chunks of reusable code and content, and little related-content lists, and automatically generated RSS feeds, and a free-text search that just works. Beat that, my own programming skills!
This sort of slip-up, though---asking someone to build you a thing, be it website, web application, or offline electronic service, and letting them instead build you the tools to build it with---is tremendously common, and I can see why. You want to think that your particular site is the unique snowflake, that your way of working only fits a certain publishing workflow, or moderation structure. Of course you do: to suggest that your notions could be implemented using off-the-shelf tools is to suggest that they too are off the shelf.
But however innovative the idea, eighty percent of its implementation is, if not the same, then of the same form. How many newly-invented white goods couldn't be fitted with a standard wrench, and how many plumbers got customers to pay for them to invent a new, never-before-seen custom tool to fit them? It's not a flattering comparison, but so it is with new ideas for using the web. Every publishing system needs ways of filtering, searching, and unpublishing content; every website with dynamic content needs to address cross-site scripting, error catching and logging, and formatting raw content; and every successful site needs to consider cacheing, spooling, and load balancing or throttling.
And while web development companies can and do solve all of these problems (you didn't necessarily ask, but Torchbox does it quite nicely, thank you very much), they have to justify to you as a client why they're better placed to solve them than people whose core business is to solve them. The same goes for application frameworks: if the company's meant to be building you an application, but they're not recommending a framework like Ruby on Rails or Django, then you should ask why. And they should be able to tell you.
Maybe the system you're end up with won't quite let you moderate content the way you're used to, or the way you're expecting to. There may well be good reasons for that---and the framework or CMS has just stopped you making a very silly mistake---but if it was just a case of it being a reasonable tradeoff of functionality and developer time in the original framework, then that's the point where your web company of choice can start to extend and build on the framework. By that time, that eighty percent is already there, and secure, and the bespoke twenty percent that every site needs can sit on a solid, reliable base.
I can't tell you how happy I've been since moving from my homegrown system---much as I loved its slickness and elegance---to Drupal---much as you can always argue about the quality of other people's code, essentially just whining that it's not quite how you would have done it. Content, after all, is born free; yet it is everywhere in custom-built chains.
