Home/Learning Centre/Digital transformation
Digital transformation

Make or Buy: when to use SaaS and when to build internally

SaaS buys speed; internal development buys control. The right choice depends on process maturity and strategic differentiation.

A strategic decision, not a technology preference

Make or Buy asks whether a capability should be created internally or sourced from a provider. For business systems, the answer is rarely completely off-the-shelf or completely custom. Most growing companies benefit from buying standard foundations, configuring them around the process and developing only the small layer that creates a genuine advantage.

The most expensive mistake is coding a process that still changes every week. Temporary operating decisions become permanent technical debt.

Compare total cost, not licence price

Include management attention. Product ownership, prioritisation, QA, security and support are permanent functions for an internal product; they do not disappear after launch.

ComponentBuy / SaaSMake internally
StartSubscription, configuration, migrationDiscovery, design, development, infrastructure
MaintenancePartly included in subscriptionInternal team, incidents and upgrades
SecurityShared responsibility with vendorFull internal responsibility
ChangeWithin product and API limitsFlexible, but every change has a cost
Time to valueWeeks for a controlled scopeMonths to a stable release
DependencyVendor, pricing and roadmapPeople, codebase and documentation

When Buy & Integrate is the stronger option

Using a ready product does not mean operating without architecture. Value comes from configuration, definitions, integrations and management discipline.

  • The process is standard: CRM, tasks, accounting or email marketing.
  • Value is needed within weeks.
  • Requirements still change frequently.
  • There is no permanent product and engineering team.
  • Mature access, audit and security functions are required.
  • Competitive advantage comes from executing the process, not owning the software.

When internal development makes sense

  • The process is stable, measured and understood.
  • Ready products directly constrain revenue or quality.
  • The logic is part of the product or competitive advantage.
  • Volume justifies the investment.
  • A long-term owner, technical team and maintenance budget exist.
  • Data, regulation or latency requires specific control.
Custom software is a product that must be owned—not a project that is simply handed over.

The hybrid path from 1 to 10

Standardise

Describe the process and remove unnecessary variation.

Buy the foundation

Use mature systems for standard capabilities and configure them lightly.

Integrate

Connect key events and data without copying everything everywhere.

Measure constraints

Document where the stack creates cost, risk or lost revenue.

Build only the proven core

If the constraint is persistent and strategic, create clear business requirements for the internal team.

A decision scorecard for management

Score each option from one to five across time to value, five-year total cost, strategic differentiation, functional fit, integrations, security, vendor or people risk and reversibility. Weight the factors for your context.

The scorecard does not replace judgment. It makes assumptions visible and gives finance, operations and technology a shared picture. Include an exit plan for data portability and continuity.

Sources and further reading

Product capabilities change. The links below are primary or official sources reviewed when this guide was published.

  1. SAP: What is cloud ERP?
  2. Asana: Business requirements document
  3. Asana: Proof of concept
Free Systems Audit

See where your business is losing time and control.

We map your processes and current tools, identify the highest-value improvements and define a practical implementation roadmap.

Get a free Systems Audit