The short answer: buy the standard workflow, build the meaningful gap
Choose off-the-shelf software when an existing product supports your essential workflow, connects to your systems, and has acceptable operating and exit costs. Choose custom software when a valuable, specific workflow cannot be served adequately through configuration or a bounded integration, and you can fund its ongoing ownership. Combine both when a standard product handles the core but a small custom component solves the missing step.
Off-the-shelf means a product sold to multiple organizations, often as SaaS. Custom means software commissioned for a particular business need. Neither label proves that a system is cheaper, safer, or a better fit. The useful comparison is between complete ways of delivering the same outcome, including the work people must do around the software.
For a B2B buyer, the decision should produce a testable boundary: what will be bought, configured, connected, or built, and who will keep it working. Avoid committing to an entire platform before you know which part of the workflow actually needs a different solution.
Start with a task, not a feature inventory
Describe one important task from trigger to completion. Who starts it? What data arrives? Who approves an exception? What tells the next team that the task is done? Separate requirements that protect the outcome from preferences about how the interface should look. A familiar screen is not evidence that the workflow works.
Ask people to show a normal case, a difficult case, and a correction. Record the repeated copying, waiting, and checking between systems. GOV.UK’s user-needs guidance connects research with operational needs and the skills required to use and manage technology. That is a useful evaluation principle for private businesses too; the government rules themselves are not obligations for every buyer.
A hypothetical distributor might need sales to quote, finance to approve exceptions, and operations to confirm delivery. Contact storage could be standard; the approval rules might be specific. Define success as a completed, traceable handoff rather than a checklist of CRM features.
Use five gates before comparing scores
Our proposed decision checklist has five gates: workflow fit, system fit, economic fit, ownership, and reversibility. Record evidence for each candidate as demonstrated, unverified, or unacceptable. A failed essential requirement should not disappear inside a weighted average of optional features. For every unverified item, name the test that would resolve it.
Workflow fit asks whether the normal task and its exceptions can be completed without an unacceptable workaround. System fit asks whether data, identity, permissions, and handoffs work across the actual tools involved. Economic fit compares the cost of delivering that same workflow over an agreed planning period, including internal effort.
Ownership asks who handles incidents, changes, releases, and supplier coordination. Reversibility asks what can be exported, reused, transferred, or retired if the choice fails. The checklist is a practical framework for this decision, not a benchmark or a claim that five gates predict a project’s return.
Compare lifetime costs on the same basis
Compare a configured product, a custom build, and a combined approach over the same period, such as three years. Include setup, subscriptions or licensing, migration, integrations, training, hosting, support, security updates, testing, planned changes, and exit work. Use supplier quotes and your own workload observations. Treat unknown costs as ranges with named assumptions.
For an off-the-shelf option, check which plan includes the required API, permissions, and export capability. For a custom option, include the people and infrastructure needed after delivery. For a combined option, include maintenance of both the purchased system and the connector. GOV.UK’s purchasing guidance explicitly considers full cost, lifecycle, organizational capability, and combined approaches.
Make hidden labor visible without presenting it as guaranteed savings. In an illustrative example, 200 weekly records needing three minutes of re-entry represent ten hours of work. Confirm the observed frequency and whether removing that step actually releases capacity. The example is arithmetic, not a NULL GROUP client result or an industry cost estimate.
Test the integration and the way out
A product having an API does not demonstrate that your workflow is supported. Test the specific records, required permissions, expected load, delayed updates, failed requests, and recovery behavior. Ask how the team will detect a missed handoff and correct it. GOV.UK’s integration guidance recommends mapping system components and testing integration compatibility rather than assuming new technology fits existing services.
Request a representative data export and inspect whether it preserves relationships, history, attachments, and identifiers needed elsewhere. Review the supplier’s current terms and the process for ending service. GOV.UK’s data guidance treats data lifecycle and supplier exit arrangements as planning concerns. Apply that principle to your evaluation rather than assuming ownership of an account guarantees a usable exit.
Custom software also needs an exit test. Specify access to source code, deployment instructions, data models, credentials under company control, and a workable handover. Buying a product changes the responsibilities you carry; commissioning software does not automatically remove dependence on a supplier.
Use project evidence without turning it into a universal recommendation
NULL GROUP designed and delivered custom CRM systems for three companies, each shaped around that team’s customer workflow. That is evidence of workflow-specific delivery. It does not establish that those companies rejected every commercial CRM, or that a custom system is the right choice for yours. The lesson is to examine the relationship and handoff a system must support.
A different boundary appears in the WhatsApp AI assistant data case study: we built infrastructure, ETLs, dashboards, reporting, marketing data, and automation for an assistant reaching close to 300,000 users. This illustrates work behind an existing product. It is not a claim that NULL GROUP built the assistant itself or that a buyer should replace every connected tool.
For a first custom component, keep scope narrow enough to test the uncertain workflow. Our note on building an MVP without a maintenance problem explains why fewer workflows can still need clear data ownership and a path to the next version. A smaller build is useful only if it proves the complete task, including recovery.
End the evaluation with a decision brief
Bring a one-page brief to the decision meeting: the task and its owner; essential requirements; candidates tested; evidence from normal and exception cases; comparable costs and assumptions; support responsibilities; and the exit path. State the selected boundary and the unresolved risk. Agree what observation would trigger a review instead of treating the choice as permanent.
Buy when the essential gates pass and the remaining differences are acceptable. Build when a material workflow gap survives testing and has a funded owner. Combine when the gap can be isolated without making two systems harder to operate than one. If the evidence is incomplete, commission a focused evaluation before a full implementation.
If your team needs help defining that boundary, NULL GROUP’s product discovery service can clarify the problem and practical options before a larger commitment. Start a conversation about your workflow with the task, current tools, and the decision you need to make.