Build vs buy? That's possibly the wrong question

This article is part of Rethinking Digital Decisions, a series inspired by my Beyond the Promise research into digital failure.

This series will explore the hidden dynamics that influence digital effectiveness in cultural organisations. Each piece looks at different aspects of how these decisions are shaped by culture, maturity, and organisational readiness, and what it really takes to make digital work well.

In so many of my conversations at the moment I keep hearing the same question from cultural organisations: "should we build something custom, or buy an existing tool?"

It sounds like a practical, binary decision, and the simplicity is wonderfully seductive. But in reality, it’s often the wrong place to start.

And that 'build or buy' question tends to skip over the most important part, which is, what do you actually need to achieve, and how ready is your organisation to make this work, whatever 'this' actually ends up being?

Before you decide what kind of solution you want, you need a much deeper conversation about what problem you're solving, who you are solving it for, what kind of organisation you are, and what you're realistically able to sustain.

Because I have seen so many organisations make decisions without clarity on those key questions, or whilst being pretty over-optimistic about their actual capacity. And it's important to consider that when you choose a tool, you’re also choosing a way of working.

So that’s what this article is about, trying to share some ways to spot the deeper questions behind the 'build vs buy' conversation, and how to get better at making digital decisions that stick.

Because there’s no simple or obvious answer. Building something custom can give you ownership, flexibility, and alignment with the unique aspects of your organisation, but it is also probably harder and more complex to deliver and comes with hidden costs, considerations around managing technical debt, and long-term maintenance challenges. Particularly if you do not have experience with this approach, or a product-centric culture at your organisation.

Off-the-shelf tools are often quicker and cheaper to implement, but might constrain you or require (significant) cultural shifts to fit around them.

A version of this conversation surfaces again and again from membership systems to ticketing, content distribution, CRM, and more.

I don’t have a magic framework (yet, sorry). But I do think this is an area where we need more honest, open discussion about what the options actually are. Not just with digital, IT and/or tech teams and suppliers, but across leadership teams, and organisations as a whole. The real questions are often strategic and cultural, not (only) technical.

As I say, "build vs buy" probably isn't actually the question you should be worried about answering right now, there are likely to be other, messier areas that need addressing first.

Mapping maturity to method

That’s why I think a genuine understanding of digital readiness is the missing piece.

Not just technical ability, but strategic clarity, an understanding of who your users are, decision-making confidence, cross-team collaboration, and appetite for change.

In practice, the “best” route often maps closely to what your organisation is actually ready for, not just what sounds exciting in a pitch.

For example:

• If your digital readiness is low, an off-the-shelf tool might provide the structure and support you need to move quickly, even if it means adapting your workflows.
• If your digital readiness is higher, you may have the strategic clarity, internal skills, and risk tolerance to justify building something bespoke.
• And sometimes, maturity lies in restraint, knowing what not to build, and focusing on culture or process first.

In other words, the 'best' approach is usually a reflection of your organisational reality and culture, not just your ambition.

That’s also why the most important factors in a project’s success aren’t always technical (in fact, they rarely are).

For example, I’m currently working on a project where the administrative user experience of the solution and customer support considerations will have a bigger long-term impact than the system’s actual feature set.

I’ve seen custom builds both thrive and flop, just as I’ve seen off-the-shelf tools liberate and frustrate.

The success or failure usually has less to do with the tool itself and more to do with how clearly the organisation understood the problem, how well they could adapt, and what they were actually ready for.

If you put too much power into an unready system and you don’t get transformation, you get stress fractures. It’s like bolting a high-speed motor onto a creaky old bike. Instead of going faster, you shake the whole thing apart.

A third option?

While “build” or “buy” dominate most discussions, there's also a potentially powerful third route: assemble (or, to keep with the B theme maybe we can call this 'bolt together').

The increasing availability of low/no-code tooling, and services such as Zapier, Airtable, Notion or IFTTT means that lightweight, adaptable automations, workflows and integrations that previously would have required specialist external developer support are now within the reach of non-specialists (I won't mention vibe coding too much here, but also...AI-assisted coding tools such as Lovable - an example of what I mean by this kind of approach).

Unfortunately the skills and mindsets that make this approach possible are rarely specifically hired for at cultural organisations, and - even when they are present - the cultural conditions for this approach to feel 'allowed' aren't always cultivated.

Because this third path requires a different kind of readiness involving product thinking, trust, clarity about the problem that needs solving, and the permission to experiment.

From bolt to buy to build

Together, these three approaches could maybe be seen as points along a continuum of risk, cost, and organisational readiness.

• Bolt together (assemble): The lightest-touch option. Use existing tools, low/no-code solutions, and simple integrations to prototype and test. This is a good way to explore the problem, surface assumptions, and learn quickly without committing too much.
• Buy: When the need is clearer, buying an off-the-shelf solution can provide stability, support, and proven functionality. It’s often the lowest-risk way of solving a problem reliably, provided the organisation is ready to adapt its workflows around the tool (this is key).
• Build: Once the need is well-established, strategically important, and uniquely tied to your organisation, building a custom solution may be the right move. But it demands product thinking, in-house capacity, and a commitment to long-term ownership and evolution.

In practice, many organisations should perhaps move through these stages over time: start small by bolting together, stabilise by buying, and only build once you’ve proven both the need and your ability to sustain it.

It’s not just a tool, it’s a practice

One thing that often gets overlooked in these conversations is that whichever route you choose (build, buy, or assemble) you’re not only choosing a tool, you’re also signing up to a way of working.

• Building something bespoke usually demands a product mindset: iterative development, user testing, managing technical debt, and a willingness to evolve the solution over time.
• Buying an off-the-shelf system often involves more change management such as adapting workflows, embedding adoption, and making sure the tool really fits into everyday practice.
• Assembling through low/no-code or lightweight integrations calls for a different kind of readiness covering trust, experimentation, and the confidence to work with 'good enough' solutions that can flex as you learn.

In other words, the technology decision can’t be separated from the cultural and organisational practices that sit around it.

Success usually comes less from the inherent qualities of the tool and more from whether the organisation has the conditions and habits to use it well.

Be honest about assumptions

This issue is not just about culture, capability and capacity, it’s also about assumptions.

When it comes to making decisions about specific approaches, even if you don’t think you're coming with assumptions, someone on your team probably is e.g. that a certain tool is best, that we should do what a peer organisation did, or that one approach is inherently better.

These assumptions often go unspoken, but they can quietly steer major decisions. Getting them out in the open early, and testing whether they’re grounded in actual need, evidence, or just comfort and familiarity, is one of the most useful things you can do at the start of any conversation about solutions.

Better questions

After thinking about all this, and reflecting on my experience in this kind of discussion I've come up with a few questions that might help conversations in this area.

1. What are we really trying to solve?

• Do we fully understand who the user is, and the user need, or are we jumping straight to assumptions and solutions?
• Are we working back from an actual need, or just an imagined one?
• Are we sure we are solving the right problem, not just the most visible one?
• Is this something we need technology to solve or is it something we could solve by working differently?

2. Is this problem unique to us or shared outside our organisation?

• If it’s common, there may already be tools or approaches that solve it well.
• Is our 'uniqueness' around this actually valuable and a strategic advantage that we want to sustain, or is it a historical or circumstantial quirk we could let go of?

3. What will we need to maintain or evolve this solution over time?

• Do we have the capacity and skills internally?
• What happens if a key person leaves?

4. How quickly do we need to move?

• Is speed-to-launch critical? Or do we have time to experiment and iterate?
• What are we basing our timelines on? Proven need or urgency, or aspiration (or something entirely made up)?

5. What hidden costs might show up later?

• Custom builds often come with long-term costs: bugs, upgrades, integrations, technical debt.
• Off-the-shelf tools might have licensing fees, user limits, training requirements, or lock-in.
• Do we understand how these considerations might show up in the specific tools or approaches we're considering?

6. Will this choice support or strain our values and working culture?

• Does the solution reinforce our ways of working or require significant change?
• How steep a learning curve are we really ready for?

7. What assumptions are we making and who’s challenging them?

• Are we being swayed by a slick demo or sales pitch?
• Are we assuming that bespoke = better, or that buying = settling?
• Are we involving the right people to make the decision, not just the most senior?
• Are we copying what others are doing without understanding why?

8. What would a low-risk, test-and-learn version of this look like?

• What’s the smallest possible version of this we could try first?
• Could we prototype a solution with tools we already have?
• What do we actually need to learn before committing to investment?
• Could we ‘rent’ or ‘borrow’ a solution temporarily to explore the shape and strength of the need?

These questions are designed to prompt reflection, not technical debate. They can also be a good framing tool when talking to suppliers, funders, or boards helping everyone stay focused on purpose, and impact, not just platforms and tools.

The benefits of asking better questions

And these prompts aren’t just theoretical. On several recent client projects, asking the right questions has helped to unlock better, clearer decisions.

In one case, the organisation faced a hard deadline, limited capacity, and low appetite for risk. Once those priorities were surfaced and agreed upon, the decision to go with an off-the-shelf tool with good wraparound support became straightforward and easy to align around internally, instead of sprinting towards a custom solution (which was the original plan).

In another, there was an assumption that only complex, high-end content commissioning would do. But a few user interviews and some structured reflection revealed a much simpler, more effective (and significantly cheaper) path forward.

And in a third, an organisation was excited about bringing in a highly customised solution. But by asking a few questions about in-house expertise, supplier stability, and awareness of issues like technical debt, we were able to shift the conversation from functionality (which they were very excited about) to feasibility (which will ultimately have a bigger positive impact on their quality of life!). That led to a more realistic and sustainable approach.

In each case, the decision itself wasn’t made easier by having more options, it was made easier by having more clarity.

3 takeaways: rethinking build vs buy

1. The real question isn’t technical, it’s organisational. Success depends less on whether you build or buy, and more on whether your organisation has the culture, governance, and capacity to make the choice work.
2. Digital maturity and readiness shapes outcomes. The same solution can succeed in one organisation and fail in another. Assess readiness before making procurement or development decisions.
3. Reframe the decision as “fit and follow-through.” Ask yourself: does this choice fit our strategy, people, and systems? Can we commit to the necessary follow-through to sustain it? These matter more than the tool itself.

If this is something you or your team are currently navigating, I’d love to hear how you’re approaching it. What’s working? What’s been harder than expected? Do you have any killer questions that help shine a light on the best way forward in any given scenario?

This feels like one of those deceptively simple problems that could benefit from a bit more shared reflection about approaches that have worked, and those that have proven tricky.