Just because we've chosen to specialise in the Drupal CMS as our main tool - that doesn't mean we recommend hitting every nail with it.
I'd like to start by quoting Jeff Goldblum's character from the 1993 blockbuster Jurassic Park, Dr. Ian Malcolm, when he says to Richard Attenborough's park owner character, John Hammond:
"Yeah, but your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."
(This is the only Jurassic Park quote I know, I hasten to add.)
It's a difficult one. When you're in the Drupal business you are able to accomplish (almost) anything you (or your clients) can conceive of. It's really easy to get carried away thinking "how are we going to implement that?", but sometimes the harsh reality is Drupal is simply not the best tool for the job and you should not even try to implement that. What you should do is say a firm but polite "no" and explain your reasoning.
Not everyone does this, but we do and, consequently, it often happens that an RFP or a client specifications document makes us think "is Drupal really the right tool for this?" While you probably could sell in a Drupal based solution for almost anything, and deliver it too, you'd probably make a bed you don't want to be lying in in 6 months' time. Granted, it's unlikely to result in the release of rabid, hungry dinosaurs, but it does have the potential to damage both your reputation and the reputation of the wider community. Recommending Drupal where it is simply not suitable is providing a poor customer experience. That hurts you, and that hurts Drupal.
I just thought I'd share a communication between ourselves and a prospective client in just such a case, to give an illustration of the sorts of things that might make alarm bells ring, and how we respond to those things as a business. In this case the prospect had decided they wanted to use Drupal, but their specification documents contained flow diagrams for processes built in to Drupal, like user registration and content creation, that were quite a departure from the default Drupal workflows. We take the view that if a customer wants to change most of the forms in a Drupal site to something other than the way Drupal already organises itself then, while possible, they are probably choosing the wrong system to start with. Starting with Drupal and then changing most of it during development is a sure sign you probably shouldn't have started with Drupal.
That being our suspicion, I responded like so:
We just had a look through the new specifications documents. The major point of concern for us is user/login registration workflows. There are two major problems with your specification and Drupal as a system:
1/ Each user account can have a multiple user access - Drupal simply does not do this. What we would advise is enabling Drupal's core OpenID support, which would mean a business could create an account and register several people's OpenID identities with that account. This would achieve the functionality you are after by allowing people to login to your Drupal site on the same account via Google, Yahoo!, MySpace, AOL, etc. OpenID identities. This is the only sensible way to achieve this. Anything else would involve ripping the core user registration process out of Drupal and replacing it with something customised. This is possible, but your budget does not allow for it.
See this link for a list of OpenID providers (it is also possible to run your own OpenID server):
2/ Various core Drupal forms seem to have specifically supplied flow diagrams in your specifications, including (but not only) the user registration form - we fear there is a disconnection here regarding understanding what Drupal is and how to play to its strengths:
Drupal is a hybrid between a framework (which basically means building an application from scratch but having tools to speed up that process) and a Content Management System (which is a ready-to-use piece of software that already behaves in a certain way that you cannot change). Drupal lies between these two worlds. You can use it as a framework, but it is not the best framework - in many respects it is much more of a ready system, a CMS, with some nice framework bits added on to give it more flexibility than other CMS'.
So, things like how the user registration form works, what content creation forms look like, etc. - these are pre-defined and changing them, while possible, can be tricky and time consuming. You have budgetary constraints that will prevent any major changes to these behaviours and, besides, if you find yourself wanting to change almost every form in Drupal then you probably need to question if Drupal is the right project in the first instance.
In short, we believe the Drupal-based application suggested in the proposal I sent over yesterday will adequately meet your requirements, but Drupal is only a sensible choice for this project if you are prepared to adjust your specifications to meet Drupal's pre-defined workflows. You can get a great application to market fast and cost-effectively with Drupal if you use the tools available. If not, and if you want to do too many things that fight against the way it is designed to work, it becomes clumsy, slow and expensive and you are better off with a PHP framework such as Zend or Symfony.
Sometimes you take an approach like this and the customer is really impressed that you've taken the time to consider their needs and make sure you're serving them well. Other times they simply strike you off the list. But in our opinion you're better off not on the list of an organisation trying to bang a square peg through a round hole.