Build, buy or partner? Takeaways from our Charity Leaders' Breakfast
Build versus buy is a question that comes up again and again in our conversations with charities, and it never seems to get any easier, which is why we brought a group of digital, technology and senior leaders together at The Lighterman in King's Cross to talk it through.
It's often framed as a simple choice between two options, but most decisions are more nuanced than that, and AI has complicated them further.
We invited speakers who have made these decisions from different directions, inside charities, as independent advisers and at Torchbox, to talk honestly about what happened, what they learned and what they would do differently, and then opened the floor so that guests could share their own experiences.
Our panel of speakers kickstarting the day.
The options have shifted, but the fundamentals haven't
To provide some context, we started the morning by outlining what we meant by each of the three routes for the purposes of the discussion. Buying meant choosing an off-the-shelf product that someone else hosts, maintains and develops, and trusting that its roadmap will keep pace with your needs, while building meant your own team writing and running the software, which gives you the most control but also full responsibility for keeping it secure, up to date and evolving. Partnering sat between the two, with an agency building the product with you, often on open source foundations, so that you own the result without needing a full product team on the payroll.
The factors that shape the decision also vary a great deal depending on the type of system, since a CRM, a CMS, an email platform and a donations platform each come with very different needs, risks and markets.
AI has made building faster and cheaper than it was even a couple of years ago. That now tips the balance more often to make a built or partnered solution the better-value, more adaptable choice.
Buying is changing too, with off-the-shelf products adding AI features at pace. This can bring real benefits but also tends to affect pricing over time and raises new questions for any buying decision, such as where your data is stored, whether it is used to train someone else's model and which AI model sits inside the product.
What hasn't changed is that charities tend to live with these choices for many years, and every pound spent on building or buying software is a pound that isn't going to the mission. Most organisations run a mix of bought, built and partnered systems, and the right answer depends on the particular system, the moment the decision is made and the people available to look after it.
This is business change rather than a technology project
A strong point of agreement was that these projects shouldn't be led purely by digital or IT teams but by the business problem they are meant to solve.
That's why sponsorship was discussed at length, with broad agreement that the right sponsor comes from the part of the organisation the change will benefit or affect, so that they are invested in the outcome and able to bring their teams along with them.
The sponsor also needs to be senior enough to work closely with the leadership team, and the senior leadership team itself needs to be visibly supportive of the change. Being an effective sponsor doesn't come naturally to everyone, and one guest shared how their organisation had provided sponsor training, while others suggested that where only one person can take on the role due to resource constraints, shared governance can help to spread the load and the risk.
A good partner can bring expertise and challenge, but they can't make the organisational decisions for you.
Kate shares insights from Sue Ryder's website redesign, including the importance of discovery and user testing.
Bring the right people with you
Technology decisions are stronger when they don't rest on one person's opinion, and the benefit of involving a wider group comes from collaboration rather than people simply going along with a decision. Your data team is one of the most valuable voices to bring in, since they usually understand where the problems lie before anyone else, while business analysts and someone who understands your architecture, both now and in the future, can help connect what the organisation needs with what gets built or bought.
Building is the easy part
Whichever route an organisation takes, the build or the purchase is rarely the hardest part, because a lot of the effort lies in everything around it. That includes the practical work of hosting, maintenance, testing, support and a roadmap for the future, which is why total cost of ownership is so often underestimated. You also need to factor in managing stakeholders and helping teams through the change itself, which is just as easy to overlook and needs the same planning and budget as the technology.
Responsibility for security shifts between the options without ever fully leaving your hands. If you build in-house, everything from patching to monitoring sits with your own team, a partner can take on much of that day-to-day work or share it with you, and buying hands the security of the platform to the vendor but leaves you with little visibility or control over how it is managed. The relationship matters too, because a partner who knows your systems will act on a security issue straight away, whereas raising the same issue with a large global vendor can leave a charity feeling like a very small fish in a very large pond. Whichever route you choose, your organisation remains accountable for its data and how it is protected.
Ivan offers his perspective on making technology decisions, from getting the right people involved to thinking about long-term costs and responsibilities.
Start with discovery, every time
All our speakers agreed that good discovery is what makes any of these decisions sound, and it is also where AI can help, since a working prototype can now be in front of users within days. One of the most candid moments of the morning came from a reflection on a platform purchase decision made under time and budget pressure, which saved money but, without time for proper discovery, locked in existing processes rather than enabling change. It was a reminder that discovery is ultimately about agreeing which problem you are trying to solve.
Questions to take away
Whichever route you're leaning towards, the questions below, drawn from our speakers and the discussion on the day, are a useful starting point for your next technology decision. They work just as well looking back, and running your organisation's last significant technology decision through them is a good way to see whether the ground has shifted enough that you would now choose differently.
- What business problem are we solving, and who in the organisation will own it?
- What do our data, our users and our teams tell us about that problem?
- Is our need likely to change as we grow?
- What must we own, such as our data and how we use AI, and what can we safely rent?
- What will this cost over five years, including maintenance, improvement and what it would cost us to leave?
Thank you
Thank you to our speakers for being so open about what has and hasn't worked for them, and to everyone who joined us and brought such thoughtful questions and experiences to the discussion. Guests came from organisations including Action for Children, Alzheimer's Research UK, Alzheimer's Society, Beacon CRM, Breast Cancer Now, Business in the Community, Catch22, Chatham House, Cystic Fibrosis Trust, Dogs Trust, Kidney Research UK, MND Association, Shelter, 350.org, Women's Aid Federation of England and Young Lives vs Cancer.
If you're weighing up a build, buy or partner decision yourself, our recent blog looks at the options and trade-offs in more detail, and you can read the blog here.
And if you'd like to test an idea with users before committing to a route, our Innovation Fund will match up to £15,000 of the cost for charities developing a proof of concept with us, which is a low-risk way to start small and put a discovery-first approach into practice.