Custom software vs off-the-shelf: choose by workflow.

Start with one complete task

Imagine a purchasing team comparing supplier quotes before creating a purchase order in its ERP. One offer includes a delivery date; another leaves it blank. The buyer needs to see the missing term, request clarification and approve the comparison before anything is handed off.

“We need procurement software” is too broad to choose a solution. A more useful requirement is: keep the offers together, compare the required terms, make missing information visible and record who approved the next step.

Test an incomplete offer as well as a complete one. If a system treats a blank delivery date as “ready to approve,” a polished comparison screen has not demonstrated the job. Conversely, an existing tool that handles the checks reliably may already be sufficient.

What changes when you buy, configure or build?

Off-the-shelf software is an existing product offered to multiple customers. Custom software is developed for a particular set of requirements. Configuration changes a product’s supported settings or workflows; an extension adds behavior through its supported interfaces or development tools.

These options can overlap. Microsoft’s Dynamics 365 extension guidance, for example, describes configuration, low-code customization and code-based extensions. Packaged software is not automatically inflexible, and a custom application still depends on the platforms and services beneath it.

If your existing Microsoft environment can support the task, our Power Platform consulting service is one relevant implementation route to evaluate. A low-code platform still needs thoughtful permissions, testing and an owner.

Run the same fit test on every option

Prepare a small demonstration script before reviewing products or commissioning a prototype. Include a normal case, a common exception, the relevant user roles and the final handoff. Ask to see the work performed with representative, redacted inputs.

For the quote-review example, the script should show how a missing delivery date is resolved, who can approve and how the approved record reaches the ERP. If a connected write is part of the scope, include a failed request and retry in the acceptance checks.

Compare the full commitment

Use the same workload, users and evaluation period for each option. Include implementation, migration, training, subscriptions or infrastructure, support, integration maintenance and your team’s time. Test how the commitment changes if usage grows or the workflow needs another role.

The UK Government Digital Service’s purchasing guidance considers full lifecycle cost, available products and delivery capability together. Those are useful questions for this comparison too. A lower entry price alone does not establish the better choice.

There is no automatic long-term cost winner. A small subscription may remain sensible; a custom component may be justified by a valuable, persistent gap. Our custom software development cost guide explains how scope and operating responsibilities affect the estimate.

Decide who will run and change it

Every route creates dependencies. With a product, check supported features, plan limits, export options and the vendor’s update process. With configuration or custom work, identify who maintains the changes and what happens when an underlying service changes.

Agree access to the relevant code or configuration, deployment accounts, documentation and data exports. Clarify licenses, handover and support terms. Paying for custom development does not by itself explain what another team could take over.

Ask the same practical security and continuity questions of every option: who can view or approve a record, how access is removed, how updates are handled and how data is recovered. The label “custom” or “off-the-shelf” does not demonstrate those controls.

When would we recommend a custom application?

We would investigate a build when an important workflow has a well-defined gap that suitable products or supported configuration do not close, and there is a credible plan to run the result. The first scope should finish that job, with clear inputs, review points and a useful output.

We would favor an existing product when it passes the actual task and its costs and responsibilities are acceptable. We would pause a build when the process changes every week, system access is uncertain or nobody can own acceptance and ongoing decisions.

Our custom web application development service explains how we turn workflow examples into agreed scope and working versions. Bring the current process and the part that does not fit; the first decision may be configuration, a product trial or a focused prototype.