I’ve had a few conversations in recent weeks with organisations who are considering recruiting an in-house developer for their CRM system, rather than use, or solely use, the services of a third-party implementer.  Please note I’m referring to the in-house developer implementing a commercial CRM application such as Salesforce.com or Microsoft Dynamics, rather than a custom system development (an approach I will discuss in a future post). So here are my thoughts on the pro’s and con’s of in-house CRM developer approach.


Cost – In principal the effective day rate for an inhouse CRM developer will be a lot cheaper than for an external resource. So, if we assumed a fully landed cost (i.e. factoring in employers national insurance, benefits, and other employee costs) for a developer of £60,000 per year, the day rate equates to around £260.

By contrast an external implementation company is generally going to be charging in the region of £800 – £1,000 per day, so, on the surface at least there’s quite a potential saving.

Harmony – I think one of the big potential pluses of having an in-house development resource is that it’s generally easier to work with them than an external development company. The relationship between the client and the implementation company can often become pretty fraught as each seeks to protect its commercial interests.

By contrast the internal developer is already paid for, and this can create a more cooperative, harmonious environment, which may be the difference between getting a project over the line or not.

Responsiveness – If you’re paying the developers salary, in principle you’ve got the option to use their time as you want. If an urgent requirement crops up, you don’t have to wait for the implementation company to assess the requirement and assign a resource – which might potentially take days or weeks depending on their workload – you can simply reprioritise their work. This can be an important consideration, particularly if the system is mission critical to the operation of the business.

Better fit – Because an in-house developer’s salary is a sunk rather than variable cost, there’s considerably less friction involved in making use of the resource compared to using the services of an implementer, where you may have to seek quotes, get the work signed off, issue purchase orders etc. This means that in-house developed systems tend to be better tuned to the needs of the users because it’s easier to get, particularly minor, tweaks and enhancements authorised.


Do you have the work? – Employing an in-house CRM developer is only going to be a cost-effective approach for larger projects. The £260 per day rate I mentioned earlier is based on around 230 days of development per year. If the development requirement is actually only 100 days per year, the effective day rate becomes £600 per day, or if it’s only 50 days the rate becomes £1,200.

It’s worth also worth noting that people tend to overestimate the amount of pure development time involved in the typical CRM system implementation. The reality is that a CRM system implementation involves a broad spectrum of skills, such as business analysis, project management, system administration and training. Development time may actually be a relatively small sub-set of the total.

This is less of an issue if the developer is multi-skilled and can take some or all of these other areas on, but, in my experience, these are pretty rare beasts. As a result, I’ve seen a lot of situations where in-house developers are clearly heavily under-employed, and, from a cost perspective at least, the employer would do better to work with an external implementation partner.

You take on the responsibility – If you’re employing the developer, then you’ve got limited come back if things go wrong. If an implementer messes up, they’re generally going to be liable for sorting things out. If the in-house developer proves incompetent, loses the plot, makes a major error, then you have to live with the consequences. This is a particular risk if you don’t have the skills or experience in-house to effectively manage the developer.

Overengineering – One of the side-effects of having a potential abundance of development resource is that it can result in overengineering, particularly if this involves lots of custom development work. This can result in a system that’s difficult to upgrade, and complex to support, without necessarily adding significant value to the system itself.

Overall, I’d say the cost argument for recruiting in-house developers is generally weak, given that there needs to be a big development requirement to make the sums work. If it’s a mission-critical system, you could certainly argue the case that an in-house capability may be more responsive to issues and new requirements, and that the easy access to resources may produce a better tuned system. But there’s a lot of risk involved with the approach. Hire the wrong person and these potential benefits could evaporate very quickly.

[Facebook] [Google] [LinkedIn] [Twitter] [Pinterest]

One thought on “Should you recruit an in-house developer for your CRM system?”

  1. Another option i did not see you address as an option
    Is implementing your crm solutionon an opensource platform
    Like sugarcrmwhere the work should be more integration and implementation vs the full build of code from scratch
    Having worked both sides of this issue implementing crm solutions based on sugarcrm and as a consultant for one of sales force premeir partners acumen solutions
    I was struck at how similar the functionality of the open source
    Sugarcrm weree a makor issue also not discussed and very important is the team support available from the outside consulting firm depending on an inhose staff member who may be quite willing but over worked can leave the project up inthe air unsupported in the event of major health issuesthat leaves the inhose staff incapacitated speaking from personal experience of a willing inhose staff member who sufferred a major stroke factor that cost iN!

    And salesforce werei

Leave a Reply

Your email address will not be published. Required fields are marked *