Skip to content

Why building your own/over complexifying is an issue, and nearly always bad

 As CRM specialists we can design all manner of solutions, from a simple fundraising implementation right through to complex programme and case delivery work.

While I am mainly speaking about CRMs here, the principles here apply to any system; it could be a website, project management tool - anything where you essentially need to configure or build something.

As consultants, we can have a tendency to want to deliver the most technically complete and beautiful solution, but we have to remember to balance this against needs, budget and ability to maintain. If we build a super slick Salesforce solution with a bunch of complex connected automations, custom screen flows, Apex code and custom components, then we have delivered you your 'Porsche'. But what if:

  • You want to maintain it yourselves afterwards
  • Something goes wrong
  • Your requirements suddenly change, meaning a bunch of rework is required
  • Your processes have changed so much as a result of this work you now have a team issue
  • You actually only needed a Corsa.

We have failed, that's what!

The same applies to custom build. It's really rare that building your own version of something where there is an off-the-shelf solution, will be the right decision for a charity. Now if you are a big charity with deep pockets, this article probably isn't for you anyway and this might not apply, but for most of that charities seeking our help it does. If you don't have buckets of cash, dedicated technical resources to maintain systems, or the expertise to validate that what's being built will be resilient and scalable, it's unlikely you'll need a custom build.

Part of being a good consultant is to push back when people think their ways of working are so unique, that an off-the-shelf solution can't be adapted and configured to work for them. Of course each charity has its own specific ways of working, but our evidence across the 60+ projects we've delivered is that there is a massive amount of commonality in what organisations do.

You need to work alongside someone who can extract that element of uniqueness and advise you on potential alternate ways of working to develop the commonality. It's also the role of a consultant to lay bare the facts about what building your own really entails, both organisationally and financially. 

 

Option Pro's Con's
Build
  • Can be exactly what you want
  • You own the intellectual property
  • 'Potentially' lower running costs (but more hidden costs)
  • Full control over roadmap and prioritisation, nothing waits for a providers release cycle
  • No licensing fees tied to user count or record volume as you scale
  • Every time you need something new = additional cost
  • You are 100% responsible for security and failover/business continuity planning
  • You are now the data processor and data controller
  • High up-front costs
  • Requires strong partner management
  • No regular product enhancements
  • Requires in-house or contracted technical capacity to maintain long-term, not just to build
  • Knowledge risk: if the developer or partner who built it leaves, knowledge can leave with them
  • Slower time to value, months of build before anyone can use it
Buy (and configure)
  • Shared responsibility model - provider is responsible for securing data hosting and compliance etc
  • Specialist software, this is literally all they do
  • (Usually) dedicated support
  • Benefit from community advancement and regular updates
  • Will likely grow with you
  • Faster time to value, typically live in a couple of months
  • Lower up-front capital cost, spread as an operating expense instead
  • Built-in compliance features (Gift Aid, GDPR tooling) maintained by the provider as regulations change
  • Higher licensing cost
  • Can't always do exactly everything you want to do
  • Roadmap dependency, features you need might not be prioritised by the vendor's broader customer base
  • Additional features may result in increased licence costs
  • Increased contacts or users may result in increased licence costs

 

 

Measurement Build Buy
Time to value Months to years Weeks to months
Total cost of ownership Lower licensing, higher maintenance Higher licensing, lower maintenance overhead
Scalability Depends entirely on your team's capacity and your budget Generally built to scale with you
Compliance upkeep Your responsibility to track and implement Usually maintained by vendor
Skills required in-house Ongoing technical/dev capacity Admin/configuration skills, less technical