Warning: mysql_real_escape_string(): Access denied for user 'dragon99'@'localhost' (using password: NO) in /home3/dragon99/public_html/wp-content/plugins/easy-contact-forms/easy-contact-forms-database.php on line 152

Warning: mysql_real_escape_string(): A link to the server could not be established in /home3/dragon99/public_html/wp-content/plugins/easy-contact-forms/easy-contact-forms-database.php on line 152
Client-Developer Relationship - Data Management Chicago | DataScopic

Client-Developer Relationship Comedy or TragedyIn the past week Client-Developer Relationship topics have shown up a lot.

You all know that I primarily focus on Data Management. Some of you also know that I also work on WordPress sites. Today’s blog post will matter to both clients and developers in Data Management, website development, and any other area where

  1. A client/user needs a custom solution and 
  2. There’s something complex in it’s daily use and/or
  3. Something complex about making foreseeable modifications

First. Consider something like a desk. If someone builds you a desk and it doesn’t meet expectations, it’s likely to still at least be functional. But it’s not the same for:

a website a VBA-driven spreadsheet
an online CRM a Project Management tool

A website needs regular updates and it can be hacked into; a project management tool needs users added and removed, tasks need to be assigned and it may need to grow beyond anything currently imaginable. These types of tools may not be functional from the start because they’re complicated. They might be functional for a while until a modification is needed, and no one in-house knows how to make the modification.

This is where Client-Developer Relationships and Communication should be Priority #1. No matter how big the client’s budget and no matter how talented the developer, both parties can get screwed if the relationship and communication aren’t solid. 

For clients with a small budget (or no budget) you can get royally screwed.


♦  Client is a nonprofit with 4 non-techie employees
♦  Developer is big-hearted and agrees to create a CRM for the nonprofit, pro bono

Throughout the development, the nonprofit senses that the developer is forcing a solution based on what she believes is good medicine for the client:

Client-Developer Dystopia

  • The solution is going to be in the cloud instead of a shared drive
  • Collaboration will be easy
  • It’ll be possible to email straight from the CRM
  • Graphs and reports are gonna be sweet sweet sweet
  • No monthly subscription

The nonprofit reluctantly goes along, even though this is sounding really complicated and more than they need. The developer delivers her masterpiece and moves on.

The nonprofit migrates its data into the monstrosity, and one day they can’t figure out how to add new fields to the CRM. Where’s the free developer?

In the process of abandoning the CRM and going back to the old ways, they accidentally merge 3 fields of data into 1 field. Various people get involved and now data is sprinkled across 5 spreadsheets.


  • Who’s going to restore the organization back to how it was pre-CRM?
  • Who’s going to do it for free?

The original developer is notified of the mess. Knowing that the organization has no money, she reluctantly agrees to help clean it up and starts doing half-assed intermittent work because she’s far beyond what she expected to be doing for free.

Client-Developer Relationship Is Serious

I’m serious!

DON’T LAUGH (It’s not funny, and it’s all too real)

Variations on this Client-Developer Relationship theme are played out far too frequently, and a lot of developers are making good money cleaning up after situations like this. It’s expensive to have one developer clean up after another.

Thus, it’s worth considering starting from scratch or paying another developer to dismantle the monstrosity and help return to the old ways.


  • Developers need to LISTEN to the client.
    • What does the client want? What do they need? What can they maintain if you’re hit by a bus?
  • Clients must stand firm in what they need and can maintain.
    • Technical, interactive tools require maintenance and support. If you’re on your own for this and have a small budget, demand that the developer create something SIMPLE that you can maintain.
  • Clients should find the money to pay a developer something—even if it’s a small gesture.
    • Clients need to have some skin in the game. Without that, clients get lax about testing, finding bugs, and remaining engaged in the process.
    • No. Bartering does not count unless there’s something pretty damned juicy.
    • Keep in mind: to be paid and respected as a professional, we have to pay and respect others as professionals.
  • The Client-Developer Relationship & Communication are paramount.
    • Better to get a developer who’s “good enough” and reliable than a developer who’s hot-shit and intermittent; or hot-shit and arrogant.

Some clients don’t realize what they’re getting into when hiring any kind of developer. It means engagement, working together to understand your needs. It means phone calls and asking you to provide content. You’ll have to road test early versions and expect it not to work perfectly. In short: There’s upheaval.

So, “take your protein pills and put your helmet on.”

You have been warned

Now, go out there and be a good steward of the world’s data.

Additional Reading

Ten Reasons Why Users Won’t Use Your Business Solution This is a great article by Ian Nicholson. He described why users won’t use a solution. I take it a step further and address the concern of a solution being used for a while and leaving the users/clients in a very regrettable predicament.

RANT: Excel vs. Excel Alternatives. My warning to web-based evangelists who are prone to creating expensive, complicated solutions that users don’t understand and can’t maintain.

Masks photo credit: Jeremy Burgin via photopin cc

Dystopia photo credit: jonny2love via photopin cc