Custom software vs. off-the-shelf? A B2B decision guide

First distinction: standard or your edge?

Accounting, email, payroll — these are standard processes. Thousands of companies run them the same way. Off-the-shelf packages (SAP, QuickBooks, Workday) are mature, secure and cheap. Building custom software here is usually a waste.

But your "competitive edge" — a proprietary pricing algorithm, a customer-specific integration, a particular operational flow — becomes generic the moment you shove it into a packaged tool. The 20 % of the business that actually generates value drops to 0 %. Here custom software is non-negotiable: if you run the same tools as your competitor, you produce the same result.

Four practical questions

Before picking a side, answer these four:

1) Is the process industry standard or company-specific? 2) Does the data model change with the outside world (billing, integrations)? If yes, packaged software or SaaS with an open API is fine. 3) Will your business model around this process shift in the next 24 months? If yes, a packaged tool's configuration ceiling will bind you. 4) Is your competitive edge hiding inside the process? If you cite the process when you explain "why customers pick us", custom software is mandatory.

Two or more "distinctive" answers (unique, concealed competitive edge) point to custom. Otherwise start with a packaged tool and migrate when you hit the ceiling — that's the cheapest strategy.

The hybrid approach: the most pragmatic choice

In real life, most B2B decisions are not "all custom" or "all off-the-shelf" — they are the smart combination of both. The playbook: run the standard layer (accounting, HR, CRM backbone, email) on best-in-class packaged software; build the differentiating layer (pricing engine, customer portal, operational flow, data transformation) as custom software integrated to the packages via APIs.

This gives you three things: (1) vendor safety and low total cost of ownership on the commodity layer, (2) full control and fast iteration on the differentiator, (3) each layer can evolve at its own pace. In practice this usually lands as "SaaS + API + a thin custom application layer". As you grow the custom layer expands; the packaged layers stay stable. At Setviva about 70 % of customers start hybrid — those who ask for a fully custom build often decide, once we map the flows, that they prefer to move standard processes to packaged tools too.

Estimating the migration cost correctly

The mistake B2B decision-makers make most often: comparing only the license fee or project price. Real cost sits below the waterline. When you move to packaged software, add: data migration and cleanup, training, productivity loss during transition, integration development, reporting customization, and process redesign. These typically total 3–5× the license fee. When you move to custom, add: design and discovery, development, testing, training, maintenance and continuous iteration, infrastructure (servers, monitoring, backups), and ownership risk (who runs it if the team leaves). These typically total 1.5–2× the build fee.

For an honest comparison, write out a 24–36 month total cost of ownership (TCO) and compare the two options on the same footing. In every Setviva proposal we present this line-item TCO upfront so the decision rests on "actually cheap", not "looks cheap". Getting the migration cost right can matter more than the choice itself.

Lock-in risk: it cuts both ways

Every decision-maker asks "what does this cost today," but almost nobody asks "who holds the leverage over me three years from now." With SaaS, the vendor writes the roadmap, not you. Contracts renew with price increases that can turn steep once the tool is wired into your daily operations; features get deprecated or shuffled into a higher tier; the vendor can be acquired and the product sunset on a timeline you didn't choose. None of this is hypothetical — it's the ordinary life cycle of software vendors, and the deeper a tool sits inside your operations, the more expensive it becomes to walk away, even if the price triples. This isn't a reason to avoid SaaS — for standard processes it's usually still the right call — but it means the "monthly fee" comparison hides the real question: how much leverage are you handing to a party whose incentives aren't yours?

Custom software turns the leverage problem inward. The risk is no longer a vendor's roadmap; it's your own team's bus factor. If the developers who built the system move on and the decisions behind it were never documented, the system quietly becomes a black box nobody wants to touch. Left unmaintained, dependencies age, security patches stop landing, and eventually "custom" turns into exactly what you built it to avoid — a fragile, legacy system. The lock-in here isn't a contract clause, it's concentrated knowledge, but the effect is identical: you can't leave without paying a steep price.

The fix is to treat exit cost as a decision criterion from day one, on both sides. For SaaS, before signing, check what data you can export and in what format, whether the contract caps price increases, and how painful leaving would actually be in practice. For custom, insist that source code ownership, infrastructure access and up-to-date documentation are contract deliverables, not favors — and pick a partner who codes for whoever inherits the system next, not just for the demo. Whichever path you choose, ask the exit question before the purchase question. The option you can walk away from is worth more than the option that looks cheapest today.