Build vs Buy: Why Most Organizations Ask This Question Too Early (And What to Ask Instead)
Last week, a nonprofit executive called me with a familiar question: "Should we build a custom fundraising platform or buy something off-the-shelf?"
Before I could answer, they launched into a detailed explanation of the fields they needed, the formulas they wanted to automate, and the features that would make their team more efficient.
I stopped them. "Let's back up," I said. "Tell me about your people first."
As a Solution Engineer at Idealist Consulting, I hear the "build vs buy" question constantly. But here's what I've learned after countless implementations: organizations that jump straight to this question are asking it too early and often framing it too narrowly.
The Real Problem: We Think Everything is Technology
The classic 'build vs. buy' debate assumes you're choosing between two options: creating something custom or purchasing something pre-made. But in reality, you're looking at a spectrum of solutions, and the best answer usually lives somewhere in the middle.
More importantly, most organizations approach this decision backwards. They start with technology, fields, formulas, and features, instead of understanding their people and processes first.
I've seen this pattern repeatedly: teams get excited about a platform's capabilities, spend months customizing it to match their existing workflows, only to discover that their staff can't or won't use it the way they intended. Or worse, they realize six months into implementation that the platform they chose fundamentally conflicts with how their organization actually operates.
A Better Framework: People, Process, Platform
Over the years, I've developed a three-step approach that leads to better decisions and smoother implementations: People, Process, Platform. Notice that 'platform' comes last.
Step 1: Understanding Your People
Before we talk about any technology, I need to understand who will actually use this system. Here are the key questions I ask every client:
- What's your team's technical comfort level?
- Some teams want something technically sophisticated, even if it's more rigid. Others need a human-centered solution with more flexibility for how people will actually use it in practice.
- Are your users rule-followers or rule-breakers?
- Will people try to work within the platform's constraints, or will they constantly try to find workarounds? This dramatically affects which type of solution will succeed.
- How stable is your staff?
- If you're bringing on new team members who will oversee the project long-term, you might choose differently than if your current team will be managing it for years.
- Is everyone aligned on the goals?
- I've seen projects fail because different departments had conflicting ideas about what success looked like, even though they all agreed on the technology.
Step 2: Mapping Your Process (Without the Platform)
Once I understand the people, we map out processes using whiteboards and post-it notes. This might sound old-fashioned, but it's intentional; I want to strip away any platform limitations and focus purely on how work actually flows through your organization.
Most clients think they know their processes, but this exercise reveals gaps every time. When you're not constrained by what your current system can do, you often discover better ways to approach the work entirely.
This process can take anywhere from a few hours to multiple sessions, depending on complexity. The key is breaking people out of the habit of immediately jumping to technical solutions.
Step 3: Platform Decision (Finally)
Only after understanding your people and processes do we talk about technology. And here's where the traditional "build vs buy" framework falls short; you're not choosing between two options, you're choosing a position on a spectrum.
The Real Spectrum: From Pure Build to Pure Buy
Let me illustrate with a fundraising example, since that's where I see this decision most often:
Pure Custom Build
You could build your entire platform from scratch: CRM, peer-to-peer fundraising, payment processing, everything. You'll get exactly what you want, but you're responsible for every line of code. This is controllable, but slow and costly.
Framework + Heavy Customization
You could use Salesforce as your foundation and build custom objects, automations, and an Experience Cloud site for peer-to-peer fundraising. You're still beholden to Salesforce's roadmap, but you're only responsible for your customizations, not the underlying platform.
Configurable Platform + Integrations
You could use Salesforce for your CRM and integrate a specialized tool like Classy for peer-to-peer fundraising. You don't get to make all the decisions, but you also don't have to solve problems like payment processing and recurring donation management that have already been built by a team of developers.
Pure Off-the-Shelf
You could adopt an all-in-one fundraising platform that handles everything out of the box. This might be cheaper if it aligns perfectly with your needs, but you'll have to adapt your processes to match the platform's assumptions.
Most successful implementations land somewhere in the middle of this spectrum.
The Integration Reality
Here's what the traditional 'build vs. buy' debate misses: in today's world, the name of the game is integration. One team might love how Platform A handles donor management, while another team prefers how Platform B manages events.
Rather than building everything from scratch to unify these preferences, smart organizations choose a robust framework (like Salesforce) that can serve as the central hub, then integrate specialized tools where it makes sense.
The tradeoff is complexity. You are now managing multiple platforms instead of one, but you're also leveraging the expertise of teams who've already solved specific problems really well.
Common Mistakes and How to Avoid Them
Mistake #1: Starting with technology instead of people and process.
Take time for discovery. As I tell clients, "An hour of preparation is worth a month of headaches."
Mistake #2: Treating it as a binary choice.
Remember the spectrum. Most organizations benefit from hybrid approaches.
Mistake #3: Skipping market analysis.
With so many solutions available, your first step should always be understanding what already exists that fits or "kinda sorta fits" your needs.
Mistake #4: Underestimating ongoing costs.
Custom builds require ongoing development resources. Purchased solutions require ongoing subscription costs and potential integration maintenance.
A Simple Decision Framework
When you're ready to make your platform decision, ask these questions in order:
- People: Who will use this, and what are their capabilities and preferences?
- Process: How does work actually flow through our organization?
- Market: What solutions already exist that could fit our needs?
- Spectrum: Where on the build-to-buy spectrum makes sense given our people, processes, and resources?
- Future: How will this decision serve us as we grow and change?
The Goldilocks Solution
In my experience, most nonprofits find their 'just right' solution somewhere in the middle of the spectrum. A platform like Salesforce provides a robust foundation that can grow and adapt, with the flexibility to add customizations and integrations as needs evolve.
The key is starting with your people and processes, not with the technology. When you understand the 'why' before you choose the 'what', you're much more likely to implement a solution that your team will actually use and that will serve your mission for years to come.
Ready to start your own platform evaluation? Begin with those whiteboard sessions. You might be surprised by what you discover when you strip away the technology and focus on what really matters: your people, your processes, and your mission. Click the button below if you're ready to get some extra support from our team of experts.
