We've all been there.
"I have this really cool idea to make my clients system wicked awesome, but it's super complex. But it would make me feel amazing to actually be able to do this, and I can put it on my blog!"
Unfortunately, unless you decide to go work for your client, you are not going to be there long term and that crazy cool thing that you have created is going to have to be supported by someone else, probably without your level of expertise.
It could be a cultural thing at the moment, you know, the whole "Go Big Or Go Home" thing. I don't know, I am not as savvy about all that cool, hip stuff anymore. But, maybe from my time in the military, we always adopted the K.I.S.S. mentality for work (look it up if you don't know what it means... I suggest Bing!), so I never have the true desire to give my customers crazy complex solutions, but ones that really will, not only work for them, but allow their staff to maintain it long-term.
I was recently reminded of this from a customer I was working with. I had originally started the project years earlier, and was brought back on to it later to help troubleshoot the system that they had, and to get them on track. When I got into the environment, I was amazed about how much more complex the solution had become, and how far from the original design it had drifted.
Now, in defense of all those who came after me, there were many challenges at the client that resulted in the system being the way it was, but I couldn't help but look at some of what was done and think to myself that it didn't have to be that way, that there was a simpler way to do it.
The hard part about being a technologist is not going straight for the cool, complex solution, but stepping back and looking at what the client really needs. In the case above, I actually rewrote everything and gave them a much simpler product in the long run, because of the lack of knowledgeable staff in the product, especially complex implementations of it.
So, how do we resolve this?
Again, look at what the client is asking for, and evaluate the staff that will be there when you are long gone.
Can you train them to the level of complexity that the system will require?
Is there enough time in the contract for you to not only develop the solution, but provide enough knowledge transfer for the staff to understand and support the system in the manner it's being developed?
If the answer is no to either of these questions, look to adjust your solution or the schedule to allow you to accommodate.
And remember...just because a complex solution would look cool, doesn't mean it's the best way to do it.