Could it be that the best CRM product for you is the one you build yourself?

Every now and then we hear from clients or prospects who have decided that their best avenue to effective CRM is to simply build their own from the ground up.

After surveying the field and being somewhat overwhelmed by all the choices out there... hosted vs. on-premise, client/server vs. stand-alone, etc., etc., all with more features than anyone could possibly understand, certainly more features than anyone could ever want to use, all with hefty price tags and/or renewal options, it certainly is tempting to simply get out the Access for Dummies book and try to create your own.

The potential benefits are enormous:

1. You can do it yourself, so you can do it quickly.
2. It's bound to be cheaper, because you are the software vendor.
3. You get exactly the product you want, because you're the one building it, to your specification.
4. Updates and improvements are "on demand," because you can add new features whenever you want.

OK; now for our morning-after reality check...

Here's how it ultimately pans out:

1. Uh-oh... this is proving to be a little more complicated than I thought. I could probably pull this off, but I don't really want to become an Access expert, and I really need to run my business; I don't have time to focus on software development. I'm going to hire a programmer. OK, so this won't be quite as inexpensive as I originally thought, but at least I'll still be getting exactly what I want when all's said and done.
2. Uh-oh... why I am I having so much trouble explaining to my programmer what features I want, and how I want them to work? This is becoming very time-consuming and expensive, not to mention tedious, and frustrating. I'd better quit while I'm ahead. At least I've got most (some?) of the features I want.
3. Uh-oh... I've found a few bugs, and I'd like them fixed. I'd also like to add a few new features... but where is my programmer? I can't reach him. He's moved on to other projects (or another job, another department, etc.). Now what am I going to do? I'm trapped in a dead-end product with no export menu!

Reality check, "corporate" version...

The preceding section describes a reality as experienced by a sole proprietor (or very small business). Here's the close equivalent in a larger organization:

1. Our on-staff IT people initially said they had the capacity and appropriate resources to do this. But, three months in to the project, it turns out that the challenges are frequently exceeding their expectations. It's time to look in to outsourcing some of this.
2. It's really quite a challenge conveying our specs to the outside programming team we hired. The project is over due and over budget; time to trim our wishlist.
3. The product is delivered and deployed, but now what? We need to re-budget to account for compatibility updates, new features, bug fixes, etc. And our outside team has had some turnover, so we're not assured even the level of product knowledge we had from the start.

Moral of the story

99 times out of a 100 (speaking conservatively) it makes more sense to go with an off-the-shelf, widely supported product. You want a product that's developed by a team of professional programmers who are experts in creating, improving, and fixing that product. You want a product that's supported by a tech support team that takes calls all day long on the various "issues" and how to work around them. Training and configuration may be available locally or via internet from resellers who are product experts and CRM experts.

Even assuming that you could pull it off perfectly, is that the best use of your resources? Think about this as an opportunity cost.

Still thinking of creating your own?

We're not saying it can't be done. In fact, we know the opposite is true. If you have the budget, people, patience, and time, you stand an excellent chance of realizing the best-case benefits outlined above and, as we said from the start, those benefits are substantial. But do approach it with eyes wide open; the pitfalls and risks are also quite substantial and not necessarily so obvious at first glance.