The wrong framing
Most build-vs-buy conversations start from the wrong place. "Should we build or buy our CRM?" is too broad a question to answer usefully. The answer depends on which parts of your CRM workflow are standard and which are specific to your business.
A better framing: for each distinct capability your business needs, ask whether your requirements are standard enough that an existing product handles them well, or specific enough that you need something purpose-built.
Most businesses end up with a mix. You buy Xero for accounting because your accounting needs are standard. You build a custom operations platform because your operational workflows are your competitive advantage. You integrate them via API.
The decision matrix
For each system or capability, score these four factors:
1. Process uniqueness (high = build)
How different are your processes from the industry standard?
- Low uniqueness: Your invoicing, payroll, and email marketing follow standard patterns. Buy.
- Medium uniqueness: Your project management has some custom stages and approval workflows. Buy and configure, or buy and integrate.
- High uniqueness: Your quoting process involves proprietary calculations, multi-party approvals, and integration with three different data sources. Build.
2. Integration density (high = build)
How many other systems does this capability need to connect with?
- Low integration: The tool works mostly standalone. A project management tool for internal use. Buy.
- Medium integration: The tool needs to send data to 2–3 other systems. Buy if native integrations exist, build adapters if they don’t.
- High integration: The tool is a hub that connects to 5+ systems and orchestrates data between them. Build, because the integration logic IS the product.
3. Competitive advantage (high = build)
Does this capability differentiate you from competitors?
- Not a differentiator: Payroll, email hosting, file storage. Buy the cheapest reliable option.
- Indirect differentiator: Your CRM processes contribute to better customer relationships. Buy and invest in configuration and training.
- Direct differentiator: Your pricing algorithm, your matching engine, your fulfilment workflow. This is your moat. Build and own it.
4. Rate of change (high = build)
How frequently do the requirements change?
- Stable: Accounting rules change once a year when tax legislation updates. Buy and let the vendor handle compliance updates.
- Moderate: Your reporting needs evolve quarterly as you enter new markets. Buy if the tool is flexible, build if it’s not.
- Rapid: Your operational processes are evolving weekly based on customer feedback and market conditions. Build, because waiting for a vendor’s product roadmap means falling behind.
The hybrid pattern
The most common outcome of this analysis is a hybrid architecture:
Buy the commodity layer. Accounting (Xero/MYOB), email (Google Workspace/Microsoft 365), payments (Stripe), communication (Slack/Teams). These are solved problems with excellent products. Don’t rebuild them.
Build the operations layer. The system that manages your specific workflows, business rules, and operational logic. This is where your competitive advantage lives and where off-the-shelf products create the most friction.
Integrate everything. APIs connect your custom operations layer to the commodity tools. Data flows automatically. Your team works in one primary system instead of switching between eight.
Cost comparison: an honest assessment
Off-the-shelf costs
- Monthly subscriptions (often per-user pricing that scales linearly)
- Configuration and customisation time
- Training and change management
- Workaround time when the tool doesn’t fit
- Integration costs for connecting tools
- Data migration when switching vendors
- Vendor lock-in risk (your data in their format, on their terms)
Custom-built costs
- Initial development (typically 8–24 weeks for an MVP)
- Ongoing maintenance and feature development
- Infrastructure hosting (cloud costs)
- Team knowledge (documentation, onboarding)
- No external support team (you own the bugs)
The hidden costs people miss
Off-the-shelf hidden cost: The cost of conforming your business to the software. When you change your workflows to match the tool instead of the other way around, you’re paying in operational efficiency every day.
Custom-built hidden cost: The cost of maintaining everything yourself. Security patches, dependency updates, and infrastructure monitoring don’t stop after the initial build. Budget 15–20% of the initial build cost annually for maintenance.
Decision checklist
Build custom software when:
- [ ] Your team spends 10+ hours per week on workarounds
- [ ] You need data from 5+ systems in a single workflow
- [ ] Your competitive advantage depends on unique processes
- [ ] You’re paying for features you don’t use across multiple subscriptions
- [ ] Scaling your business means scaling your admin team proportionally
Buy off-the-shelf when:
- [ ] Your processes are standard for your industry
- [ ] The tool’s feature set covers 80%+ of your needs
- [ ] Integration requirements are minimal or well-supported
- [ ] You don’t have the budget for ongoing development
- [ ] The tool is mature and unlikely to be discontinued
The phased approach
If you’re unsure, start with the lowest-risk option:
Phase 1: Buy the best-fit off-the-shelf tool. Use it for 6 months. Document every workaround, every feature gap, and every integration problem.
Phase 2: Evaluate. If the workarounds are manageable and the tool is working for 80%+ of your needs, stay with it. Invest in better configuration and training.
Phase 3: If the workarounds are consuming significant time, you have a detailed specification for what custom software needs to do , based on real operational experience, not guesswork.
This approach costs more in total time but dramatically reduces the risk of building the wrong thing. The worst outcome in software isn’t choosing the wrong tool , it’s building a custom system that doesn’t solve the actual problem because the requirements were guessed instead of discovered.