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

First distinction: standard or your edge?

For a standard task, first test what the packaged product actually supports. An accounting or CRM label does not prove that permissions, reports and integrations fit your workflow.

A company-specific workflow does not automatically require custom development either. Try configuration and API options on a representative end-to-end case. Base the choice on unmet requirements rather than a brand or a claim of differentiation.

Four practical questions

1) Which inputs, outputs and exceptions are required? 2) Who may access the data, and how can it be exported? 3) What must change when volume or business rules change? 4) Who handles an outage, and how is the previous state restored?

Run the same acceptance cases against each option. Eliminate options that fail a mandatory condition; compare the rest on cost, maintenance and usability.

When does a hybrid approach fit?

A packaged CRM or accounting product can work with a custom customer portal. First confirm API access, usage limits, licensing rights and failure handling.

Name the system of record, duplicate-prevention rule and owner of synchronisation failures. A hybrid is not inherently cheaper or safer: include the effort of operating the complete chain.

Estimating the migration cost correctly

Alongside licence or development fees, list setup, data cleanup and migration, training, integration, infrastructure, monitoring, support and exit costs. Use the same scope and evaluation period.

Calculate vendor quotes against expected users and transactions; show lower- and higher-volume scenarios separately. Do not assume a fixed maintenance percentage, universal cost multiplier or guaranteed payback period. Keep unknown costs as open quotation questions rather than treating them as zero.

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 team's dependence on a few people who hold critical knowledge. 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.