The question isn't really "build or buy." It's "where does this system sit in your business, and what happens when it doesn't fit?"
Most businesses run on a mix of off-the-shelf software and custom tools. The trick is knowing which category each system belongs in, and recognising when something has drifted into the wrong one.
This guide provides a practical framework for making that decision. We're not here to sell you custom development. Sometimes the right answer is a £50/month SaaS subscription. But sometimes it isn't, and getting that wrong costs years and real money.
The Real Question Behind Build vs Buy
Most build-vs-buy discussions focus on features. "Does this tool have what we need?" That's the wrong starting point. Features are table stakes. The real questions concern fit, control, and long-term cost.
The better questions:
-
How central is this to how we operate? Is this a commodity function (email, calendars) or does it define how we deliver value to customers?
-
How often does our process change? Are we locked into an industry-standard workflow, or do we iterate constantly on how we do things?
-
What happens when we outgrow it? Can we migrate away easily, or does this become a prison?
-
Who controls the roadmap? If we need a feature, can we build it, or are we waiting on a vendor's priorities?
These questions reveal whether you're choosing a tool or choosing a dependency. A tool serves you. A dependency shapes you. That distinction matters more than any feature comparison.
The Core vs Commodity Framework
Every system in your business falls somewhere on a spectrum between commodity and core. Understanding where a system sits determines whether buying or building makes sense. This concept is well articulated in Wardley Mapping, a framework for visualising how components evolve from genesis to commodity over time.
| Characteristic | Commodity Systems | Core Systems |
|---|---|---|
| Definition | Everyone in your industry does this the same way | How you do this is part of what makes you different |
| Examples | Email, payroll, document storage, password management | Order processing, client delivery, pricing, scheduling |
| If it fails | Annoying, but recoverable | Operations grind to a halt |
| Competitive impact | None. No one wins by having better email. | High. This is where you create value. |
| Right approach | Buy the best commodity option | Consider building or heavily customising |
The mistake most businesses make is treating core systems as commodities. They buy a generic CRM when their sales process is genuinely different. They force their operations into a project management tool built for a different industry. The tool saves money upfront but costs far more in friction, workarounds, and missed opportunities. This is closely related to the question of owning versus renting your operational systems.
When Off-the-Shelf is the Right Answer
Custom software is expensive and slow compared to buying something that already exists. For many systems, buying is unambiguously correct. The skill is knowing which ones.
Buy when the process is commodity
Email, basic accounting, document storage, password management, standard HR. These aren't competitive advantages. They're table stakes.
You differentiate by what your team does, not by having better password management.
Buy when domain expertise is specialised
Payment processing (Stripe handles PCI compliance), email deliverability (Postmark, Mailgun), video conferencing (Zoom).
These vendors have invested millions. Let them.
Buy when you're still figuring things out
Early-stage businesses should almost always buy. You don't know enough about your processes yet.
Outgrow cheap tools first. Then you'll know what you actually need.
Industry-Specific Examples: When Buying Works
Some functions are so well-served by existing software that building your own would be foolish. Consider these scenarios where buying is the clear winner:
A recruitment agency needs an applicant tracking system
The recruitment workflow (source, screen, interview, offer) is standardised across the industry. Dozens of mature ATS products exist, refined over years. The agency's competitive advantage is their relationships and judgement, not their software.
Verdict: Buy a specialist ATS. Bullhorn, Greenhouse, or similar. Focus energy on what actually differentiates you.
An e-commerce business needs inventory management
Basic inventory tracking (stock levels, reorder points, warehouse locations) is a solved problem. Products like TradeGecko, Cin7, or Brightpearl handle this well. Unless the business has genuinely unusual inventory requirements, the standard approach works.
Verdict: Buy specialist inventory software. Only consider building if your fulfilment model is genuinely different from standard retail.
A consulting firm needs time tracking
Recording hours against projects and generating invoices is standard practice. Harvest, Toggl, or Clockify do this perfectly well. The firm's value comes from their expertise, not from innovative time tracking.
Verdict: Buy time tracking software. Integrate it with your invoicing. Move on.
When Custom Software Makes Sense
Custom development is warranted when off-the-shelf software creates more friction than it removes, or when your competitive advantage depends on doing something differently. This isn't about being special for its own sake. It's about recognising when generic tools genuinely don't fit.
Build when the system defines your operations
The order management system at a logistics company. The case management system at a law firm. The production scheduling system at a manufacturer.
These systems encode your specific way of working. Forcing them into generic software means forcing your business into a generic shape.
Build when you're drowning in workarounds
Spreadsheets that "live alongside" your official system. Manual processes to move data between tools. Staff who "just know" how things actually work.
Workarounds are expensive. At some point, their cost exceeds the cost of building what you need.
Build when you need control
Off-the-shelf means accepting someone else's data model, feature roadmap, pricing changes, uptime, and data policies.
For peripheral systems, this is fine. For central systems, it's a strategic vulnerability.
Build when integration is the real problem
Sometimes individual tools work fine, but they don't work together. Data lives in silos. Staff copy information between systems.
Often the answer is building a custom layer that connects existing tools into a coherent whole.
Industry-Specific Examples: When Building Works
These scenarios illustrate when custom development creates genuine value:
A specialist manufacturer with complex quoting
A company that fabricates custom metal components receives enquiries with unique specifications. Each quote involves materials calculations, tolerances, machine time estimates, and finishing options. Generic quoting software can't capture this complexity. Staff spend hours per quote, and errors are common.
Verdict: Build a custom quoting system. Encode your pricing logic, validate inputs, generate professional quotes in minutes. The time savings on even a few quotes per week justify the investment.
A property management company with specific workflows
A company managing commercial properties has developed specific procedures for maintenance, tenant communications, and lease renewals that differ from residential norms. Generic property management software is designed for residential lettings. The mismatch creates constant friction.
Verdict: Build a custom operations platform. Encode your specific workflows, integrate with accounting, and create a single source of truth for property status.
A logistics company with unusual routing constraints
A delivery company operates under constraints that standard routing software doesn't handle: time windows based on customer type, vehicle restrictions for certain locations, driver certifications for hazardous goods, and complex multi-drop optimisation.
Verdict: Build custom routing and dispatch software. The efficiency gains from optimised routing compound with every delivery.
The Hybrid Approach
Most businesses end up with a mix. This isn't a compromise; it's the optimal strategy. The goal is owning what matters and renting what doesn't.
Commodity tools
Email, accounting, documents, calendars, password management. Buy the best option and don't think about it again.
Specialist SaaS
Payments (Stripe), marketing automation, analytics, specialised compliance tools. Use vendor expertise where it's genuinely deep.
Custom software
Your operational core. The systems that encode how you actually work and deliver value to customers.
Integration layer
Custom middleware connecting everything. Data flows where it needs to go without manual intervention.
The goal isn't to build everything yourself. It's to own the parts that matter and rent the rest. A well-designed hybrid architecture gives you the best of both worlds: commodity convenience where appropriate, and tailored precision where it counts. This is the essence of vertical integration for software.
Total Cost of Ownership: The Real Calculation
Build vs buy decisions often focus on upfront costs. Custom development costs £50,000; that SaaS subscription costs £500/month. The maths seems obvious. But this comparison misses most of the picture.
The True Cost of "Buying"
A SaaS subscription has visible costs (the monthly fee) and hidden costs (everything else):
| Cost Category | What It Includes | Typical Impact |
|---|---|---|
| Subscription fees | Monthly or annual payment | Visible and predictable (until price increases) |
| Implementation | Setup, data migration, configuration | Often 2-5x the first year's subscription |
| Training | Getting staff competent with the new system | Days to weeks of reduced productivity |
| Workarounds | Staff time spent on manual processes the tool doesn't support | Often the largest hidden cost. Hours per week, forever. |
| Integration | Connecting the tool to other systems | Initial setup plus ongoing maintenance |
| Opportunity cost | Things you can't do because the tool doesn't support them | Impossible to measure but often significant |
| Exit cost | Cost of migrating to something else when you outgrow it | Often deferred until crisis point |
The True Cost of "Building"
Custom software also has visible and hidden costs:
| Cost Category | What It Includes | Typical Impact |
|---|---|---|
| Development | Initial build cost | The number everyone focuses on |
| Specification | Time spent defining requirements | Critical but often underestimated |
| Hosting | Infrastructure costs | Usually modest for business applications |
| Maintenance | Bug fixes, security updates, minor changes | Typically 15-20% of initial build cost per year |
| Evolution | New features as requirements change | Ongoing but controlled. You decide the pace. |
A Worked Example
Consider a mid-sized professional services firm evaluating options for their project and resource management:
Option A: Enterprise SaaS
- Subscription: £1,500/month (£18,000/year)
- Implementation partner: £25,000
- Training: £5,000
- Annual workaround cost: Staff spend 10 hours/week on processes the tool doesn't support. At £40/hour loaded cost, that's £20,800/year.
- 5-year total: £25,000 + £5,000 + (£18,000 × 5) + (£20,800 × 5) = £224,000
Option B: Custom Build
- Development: £75,000
- Hosting: £200/month (£12,000 over 5 years)
- Maintenance: £12,000/year (16% of build cost)
- Feature additions: £15,000/year average
- 5-year total: £75,000 + £12,000 + (£12,000 × 5) + (£15,000 × 5) = £222,000
At first glance, the costs are similar. But the custom build eliminates the workaround cost entirely. It exactly fits how the firm operates. Staff spend their time on client work, not fighting software. And crucially, the firm owns an asset that compounds in value as they add features, while the SaaS subscription is pure expense.
The break-even point shifts earlier when workaround costs are higher, when subscription costs are higher, or when the mismatch between off-the-shelf software and actual needs is greater.
Timing: When in Your Growth to Make This Decision
The right answer depends on where your business is in its lifecycle. What makes sense for a startup doesn't make sense for an established company, and vice versa.
Startup
0-10 employees
Growth
10-50 employees
Scale
50-200 employees
Enterprise
200+ employees
Startup Phase (0-10 employees): Buy Almost Everything
At this stage, your processes are still forming. You don't yet know what "good" looks like for your business. Building custom software would lock in assumptions that will change.
Focus on cheap, flexible tools. Spreadsheets are fine. Basic SaaS subscriptions are fine. The goal is learning what your business actually needs, not optimising processes you haven't figured out yet.
Exception: If the product you're selling is software, obviously build that. But your internal operations should run on commodity tools.
Growth Phase (10-50 employees): Identify the Friction
This is when the seams start to show. The spreadsheet that worked for 5 people breaks with 20. The CRM that handled 50 leads per month struggles with 500. You start hearing phrases like "we have a workaround for that" and "only Sarah knows how that works."
Now is the time to identify which systems are creating the most friction. Which processes are unique to how you operate? Which workarounds consume the most time? This phase is about understanding where custom software would create the most value.
Key activity: Document your actual workflows. Map where data lives and how it moves. Identify the gaps between how you work and what your tools support.
Scale Phase (50-200 employees): Build the Core
By now, your processes are established. You know what works and what doesn't. The cost of workarounds is substantial and measurable. This is often the right time to invest in custom software for your core operations.
You have enough volume to justify the investment. You understand your requirements well enough to specify them. And you have enough runway to absorb the development time.
Key activity: Build custom software for your core operational systems. Keep commodity functions on SaaS. Create an integration layer that connects everything.
Enterprise Phase (200+ employees): Optimise and Own
Large organisations often over-rely on enterprise SaaS, paying for platforms designed for the average of all their customers. Custom development at this scale offers significant advantages: lower per-seat costs, exact fit to processes, and reduced vendor dependency.
Key activity: Evaluate enterprise subscriptions critically. Consider building replacements for the most expensive or poorly-fitting platforms. Invest in internal development capability.
Signs You're Ready to Build
These indicators suggest custom development would create value for your business. The more that apply, the stronger the case.
Signs You Should Keep Buying
These indicators suggest off-the-shelf software remains the right choice. Building would be premature or wasteful.
How to Decide: A Practical Framework
When evaluating a specific system, work through these questions in order:
Commodity or differentiator?
If every competitor handles this the same way, buy. If your approach is what makes you competitive, consider building. Be honest about whether you're genuinely different or just attached to your current way of doing things.
How much are you bending?
Some adaptation is normal. But if you're redesigning your operations around software limitations, you've got it backwards. List the workarounds. Estimate their cost. Compare to the cost of building what you need.
Total cost of workarounds?
Add up time spent on manual processes, data reconciliation, and training people on workarounds. This is real money. A system that eliminates 10 hours per week of workaround time saves over £20,000 per year at typical loaded labour costs.
What's the exit cost?
If this vendor doubles prices or gets acquired, can you leave? Is your data portable? The more dependent you are, the more risk you're accepting. For commodity systems, this risk is tolerable. For core systems, it may not be.
What's the five-year view?
Project forward. Where will your business be in five years? Will this system still fit? Will you have outgrown it? The right time to plan for scale is before you need it, not after you've hit the ceiling.
Can you specify what you need?
If you can clearly describe your requirements, custom development is feasible. If you're vague on what you actually need, buy something and use it until your requirements crystallise.
Common Mistakes
After twenty years of helping businesses with this decision, we've seen the same mistakes repeatedly. Here are the most expensive ones:
| Mistake | Why It's a Problem | How to Avoid It |
|---|---|---|
| Building too early | Custom software locks in assumptions. If you're still learning what your business needs, you'll build the wrong thing. | Wait until your processes are stable and you can clearly articulate requirements. |
| Buying when you've clearly outgrown it | Sunk cost fallacy. "We've invested so much" isn't a reason to keep suffering. The investment is spent regardless of what you do next. | Calculate the ongoing cost of workarounds. Compare to the cost of building what you need. |
| Underestimating integration costs | Individual tools might be cheap. Connecting them (and keeping them connected) adds up. Vendor API changes break integrations. Data formats don't match. | Factor integration into total cost of ownership. Consider whether a unified system would be cheaper than connecting multiple tools. |
| Overestimating your uniqueness | Sometimes the off-the-shelf way is better than your current way. Not every process difference is a competitive advantage. Some are just habits. | Be honest about whether your way is genuinely better or just familiar. Would you adopt the standard approach if you were starting fresh? |
| Comparing feature lists instead of fit | A tool with 100 features you don't use isn't better than one with 10 features you do use. Feature count is marketing, not value. | Map your actual workflows. Evaluate tools against those specific workflows, not against each other's feature lists. |
| Ignoring the roadmap question | If the feature you need isn't built, when will it be? Never, if the vendor's priorities don't align with yours. | For core systems, control over the roadmap is a key criterion. You need to be able to build features when you need them. |
| Choosing based on today's needs only | A system that fits today but not next year is a migration project waiting to happen. Migration is expensive and disruptive. | Consider the five-year view. Will this system grow with you? |
What We Recommend
After twenty years of this, we've developed instincts for when custom development creates value and when it doesn't. Here's our general guidance:
For commodity functions: Buy without hesitation
Email (Google Workspace, Microsoft 365), accounting (Xero, QuickBooks), documents (Google Drive, Dropbox), passwords (1Password, Bitwarden). These are solved problems. Use the best commodity option and focus your energy elsewhere.
For specialist functions: Buy from specialists
Payments (Stripe), email delivery (Postmark), video (Zoom), analytics (Mixpanel, Amplitude). These vendors have invested heavily in hard problems. Let them handle the complexity. Your job is to use their services effectively.
For core operations: Consider building
Order management, project delivery, client onboarding, resource scheduling, custom workflows. These systems encode how your business actually works. If they're genuinely different from standard approaches, building creates lasting value.
For integration: Almost always build
The layer that connects your systems together is almost always custom. Even if you use commodity tools everywhere, the way they connect is unique to your business. A custom integration layer gives you control over data flow without replacing working tools.
The Outcome: Getting This Right
When you make good build-vs-buy decisions, your technology stack becomes an asset rather than a liability. Here's what that looks like:
-
Commodity tools that just work Email, accounting, documents. Standard tools for standard problems. No friction, no thought required.
-
Core systems that fit exactly Your operational processes run on software that matches how you work. No workarounds, no bending.
-
Data flowing where it needs to go Information moves between systems automatically. No manual copying, no data entry errors.
-
Control where it matters You own the systems that define your operations. The roadmap is yours. The data is yours.
-
Reasonable costs Not paying for features you don't use. Not paying workaround costs. Not locked into increasing subscriptions.
-
Room to grow Systems that scale with your business. No ceiling approaching. No migration project looming.
This is what a well-designed technology stack feels like: calm, efficient, under control. Tools serving the business rather than the business serving the tools.
Further Reading
- In Defense of Not-Invented-Here Syndrome - Joel Spolsky's classic essay on when building your own makes strategic sense
- Sacrificial Architecture - Martin Fowler on accepting that systems will eventually be replaced
Let's Talk Through It
If you're wrestling with a build-vs-buy decision, we're happy to talk through it. No obligation, no pitch. Just practical advice on whether custom software makes sense for your situation. We'll tell you honestly if the right answer is to buy something off the shelf.
Book a discovery call →