Custom Software vs SaaS: A Decision Framework

The question is rarely build or buy

Most build-versus-buy debates collapse into a false binary: write it ourselves, or sign a SaaS contract. The decision that actually determines outcomes is more granular. For any given capability you are choosing a position on a spectrum that runs from pure commodity SaaS, through configured platforms, embedded and white-label components, open-source assembled on managed infrastructure, all the way to fully bespoke systems. The engineering question is not *whether* to build, but *which slice* of the value chain is worth owning and which is a distraction from it.

At Baalvion we make this decision constantly while operating the Baalvion Operating System, which unifies commerce, finance, compliance, logistics, and intelligence into one multi-tenant fabric across 198 markets. We buy commodity infrastructure aggressively — managed databases, object storage, email delivery — and we build the things that *are* the product: the trade orchestration engine, the cross-border settlement ledger, the compliance scoring models. The framework below is the same one we apply internally, distilled into four axes and a scoring matrix you can run in an afternoon.

Axis 1: Total cost of ownership, not sticker price

SaaS looks cheap because the cost is legible — a per-seat or usage line item on a monthly invoice. Custom software looks expensive because the cost is front-loaded into salaries you already pay. Both intuitions are wrong at scale. The honest comparison is total cost of ownership (TCO) over a three-to-five-year horizon, and it has to include the costs that never appear on a quote.

The practical move is to model both curves, not both points. Plot subscription cost against your projected growth, then overlay the largely fixed cost of an owned system. Where the lines cross is your real decision boundary — and for high-volume core capabilities, that crossover often arrives sooner than finance expects.

Axis 2: Control and the cost of someone else's roadmap

Control is the axis teams underweight until it hurts. With SaaS you inherit a vendor's roadmap, their release cadence, their definition of an edge case, and their tolerance for your compliance regime. For a generic capability — payroll, helpdesk ticketing, expense management — that trade is excellent. Someone else carries the maintenance burden and the regulatory drift, and you get a better product than you would have built.

Control becomes decisive when the capability touches your differentiation or your regulatory surface. In our governance and compliance work, KYC/AML logic and jurisdiction-specific rules change faster than any third party will reprioritise their backlog. Owning that engine means a regulatory change in one of 180+ jurisdictions is a deploy, not a support ticket waiting in a vendor's queue. Ask a blunt question of every capability: if this breaks or needs to change at 2 a.m. before a launch, who can fix it — your team, or a vendor's tier-two support? The answer reveals how much control you actually have.

Axis 3: Time-to-value and the speed trap

SaaS wins on time-to-value almost by definition — sign up, configure, integrate, ship. For validating a hypothesis or entering a market quickly, that speed is genuinely strategic, and refusing to use it is engineering vanity. The trap is mistaking a fast start for a fast finish. Configuration-heavy platforms accumulate hidden complexity: brittle webhook chains, data living in three systems of record, and integration code that becomes its own unmaintained product.

Custom builds invert the curve. They are slow to first value and fast to incremental value, because every subsequent feature compounds on a foundation you control. A useful hybrid pattern is the strangler-fig migration: wrap a SaaS dependency behind your own interface, ship on the vendor immediately, and replace the internals later without touching callers when the economics or control requirements flip. You buy speed today and preserve the option to own tomorrow — which is usually the right answer for a capability whose future you cannot yet see clearly.

Axis 4: Lock-in and exit cost

Every dependency is a bet on a relationship, and lock-in is the cost of being wrong about that bet. It hides in several places, and the dangerous kinds are the ones that are invisible until you try to leave.

Open-source-on-managed-infrastructure is frequently the sweet spot precisely because it minimises lock-in: you get vendor-grade operations with the freedom to self-host or migrate. When we build commerce surfaces like Amarisé luxury commerce, we deliberately keep the catalogue, identity, and payment integrations behind our own abstractions so no single provider can hold the roadmap hostage.

The decision matrix

Reduce the four axes to a weighted score. For each capability, rate it 1–5 on each axis (5 always favouring the choice), apply a weight, and compare the totals. The weights matter more than the precision of any single score, so calibrate them to your situation before you start rating.

Run the matrix and a pattern emerges that maps cleanly onto how mature platform teams actually allocate effort. Commodity capabilities — auth providers, CDNs, email, analytics — score toward buy and should be bought without sentiment. Core differentiating capabilities — your pricing engine, your orchestration layer, your proprietary models — score toward build and justify the maintenance burden. The large middle ground is where the hybrid patterns earn their keep: buy now, abstract carefully, and let the matrix tell you when the crossover has arrived.

How Baalvion applies the framework

BOS is a worked example of the matrix in action. The settlement ledger that powers real-time cross-border settlement is fully owned: it is core, high-volume, regulatorily sensitive, and far past any vendor's TCO crossover — a textbook build. Conversely, observability, managed Postgres, and message queues are bought, because reinventing them would be a control fantasy with no differentiation payoff. The discipline is not ideological; it is the same scored decision, run capability by capability, and revisited as volume and regulation move the lines.

If you are weighing a build-versus-buy decision on something genuinely core to your business, our custom software development and technology consulting practices run this exact framework with clients — including the parts most teams skip, like modelling the TCO crossover honestly and designing the anti-corruption layer before the first line of integration code. The goal is never to build for its own sake. It is to own what differentiates you, buy what does not, and keep the option to change your mind cheap.