When Does Your Business Need Custom Software Instead of SaaS?

History and context

The real decision is capability ownership

The build-versus-buy debate is usually framed too narrowly. A modern company may buy accounting, payment and messaging services while owning the platform that coordinates pricing, orders, inventory, booking or operations. The architecture question is not whether software should be custom; it is which business capabilities deserve direct control over behaviour, roadmap and data.

Where SaaS is the rational choice

SaaS is usually strongest when a workflow is mature, standard and non-differentiating. Email, payroll, generic CRM, standard accounting and document collaboration are obvious examples. Rebuilding them transfers maintenance responsibility to your own team without creating meaningful market advantage.

When custom software becomes justified

Custom development becomes credible when the company's operating model repeatedly conflicts with standard software. Common signals are spreadsheet reconciliation, duplicate data entry, unusual pricing rules, multi-step approval logic, resource-based booking, channel-specific product rules, and a growing number of integrations that all depend on the same core data.

If staff have created spreadsheets to compensate for the software, the business already has a custom system. It is simply implemented through manual labour.

A practical economic model

Licence price alone is a weak comparison. The meaningful comparison is total operating cost over several years.

SaaS total cost =
  subscription
+ add-ons
+ integration
+ manual reconciliation
+ workflow compromises
+ switching cost

Custom platform total cost =
  discovery
+ design
+ development
+ cloud infrastructure
+ security
+ maintenance
+ support

A £1,000 monthly SaaS subscription may be cheaper than custom engineering. It may also be more expensive if it creates hundreds of hours of recurring manual work or prevents the business from launching important commercial models.

How we structure owned business logic

Rules that affect money or operational state should live in a shared backend rather than being duplicated across websites and POS applications.

public sealed class SalesOfferEvaluator
{
    public DiscountResult Evaluate(
        SalesOffer offer,
        PricingContext context)
    {
        if (!offer.IsActive)
            return DiscountResult.NotApplicable();

        if (!offer.IsWithinValidity(context.Now))
            return DiscountResult.NotApplicable();

        if (!offer.TargetRule.Matches(context.Items))
            return DiscountResult.NotApplicable();

        return offer.Calculate(context);
    }
}

Real-world situations

Business value and decision criteria

The strongest rule is simple: buy commodity capability, integrate where the boundary is stable, and build only where ownership creates durable leverage.

References