Compare custom development and off-the-shelf software

A business needs a way to approve customer documents. One supplier recommends an existing product; another proposes a custom application. Both can offer plausible arguments. Without shared test cases, however, the comparison easily becomes a contest between marketing statements: “available quickly” meets “completely flexible”, while nobody checks the actual work.

This guide develops a reviewable selection process for an explicitly fictional business. It names no winning products and quotes no actual supplier prices. Instead, it connects tasks, evidence, integration questions and cost. The evidence scale is our own working model. It replaces neither a security assessment nor acceptance of the eventual complete system.

1. Clarify the business task before choosing a product category

Describe a complete transaction. In our example, an employee uploads a document, an authorised person approves it and the correct customer retrieves the approved version. An unapproved file or one belonging to another customer must not appear. A later correction must remain understandable rather than silently replacing the decision history.

This is more useful than “we need an AI portal”. It identifies people, states and boundaries. Next ask which parts genuinely cause problems today. Perhaps the business only lacks an explicit approval step. Alternatively, the difficult core may be reliable customer mapping across several existing systems with different identifiers.

State what is initially outside the scope as well. Payment processing or public document search can be excluded from the examined workflow. This is not a way of artificially shrinking the project. It creates a common boundary that distinguishes later additions from the task that was originally evaluated.

The GOV.UK purchasing-strategy guidance relates building, buying and combined approaches to needs and available capabilities. Its administrative requirements do not automatically apply to a private business. Our selection process uses the methodological starting point only: the decision should be explained by the actual job.

2. Allow more than two possible approaches

“Standard or custom” is often too coarse a distinction. An existing product may fit without alteration. It may become suitable through configuration or require a bounded extension. A separate application can itself use established components instead of rebuilding every technical detail. These differences affect how the result is operated and maintained.

Identify which approach each quotation actually proposes. The label “standard” says little when essential tasks require substantial additional scripts. Equally, a custom interface does not necessarily imply an entirely independent platform. Ask what will actually be changed, which supported mechanisms will be used and who is responsible for those changes.

The GDS discussion of building or buying includes combined approaches and the risk of excessive product customisation. Our practical conclusion is to map the boundary between unchanged product, configuration and custom additions. That boundary will matter more during maintenance than the label printed on the quotation.

3. Separate essential requirements from preferences

An essential requirement needs a reason. Correct customer assignment is indispensable for the fictional document portal. A particular home-screen appearance may instead be a design preference. Combining both in one long wish list makes it easier for an impressive demonstration to distract from the most important business question.

Express each essential requirement as an observable outcome. “Good permissions” is difficult to accept formally. “A customer cannot retrieve another customer's document through either the list or a directly entered address” describes a testable slice. Add the roles, document states and access routes that belong to that test.

Not every existing habit is essential. If employees currently copy one record three times, the replacement may remove that work. Check whether a requirement describes a business purpose or merely the current sequence of clicks. A sensibly adjusted process can be better than a perfect digital reproduction of an avoidable detour.

A concise decision register contains an identifier, description, rationale, test case and owner. Keep identifiers consistent across options. That makes it possible to explain which exact evidence supports each requirement. The register must remain short enough for business owners to read and use when resolving open questions.

4. Test options with the same sample

Provide every option with the same fictional or appropriately approved test data. Include different document states, duplicate filenames and a changed customer assignment. An off-the-shelf supplier should not be evaluated solely on a prepared ideal case while the custom option is already expected to handle every difficult legacy record.

Define expected results before running the test. For an unapproved document, the expectation might be “not visible to the customer, identifiable internally as a draft”. Also state how failure will be detected. A screenshot of a successful normal case does not establish correct handling of deliberately unsuitable inputs.

Check the whole journey rather than isolated screens. A file may upload correctly and then appear to the wrong person. An export can look complete while losing relationships. Your sample should therefore contain connected business cases with known starting conditions, intermediate states and final outcomes.

Record the environment, product version, configuration and date. A statement about an earlier version does not automatically cover a later package. An extended standard product needs to be assessed together with its extension. A successful test of the underlying product alone says nothing about the newly introduced connection.

5. Describe evidence with an explicit scale

Our four-level scale records how a specific claim is supported. Level zero means unresolved. Level one is a documented supplier statement, level two an understandable demonstration and level three a controlled test performed for your evaluation. A failed test remains failed even when the level of evidence is high.

These numbers are not percentages or equal mathematical distances on a quality scale. Level three does not mean three times as secure as level one. Do not add the levels to manufacture an apparently objective overall winner. They help identify missing evidence, not create a scientific ranking.

For a decisive essential requirement, our fictional selection model asks for a successful controlled test. A bounded prototype can initially provide that evidence for an application that does not yet exist. It proves its specific task only. It is neither the complete application nor a replacement for later acceptance and security verification.

6. Include interfaces and the existing environment

A solution rarely works alone. In this example, customer data comes from an existing system, documents originate in another workflow and notifications use a separate sending route. List each connection with its source, destination, trigger and expected acknowledgement. “It has an API” does not yet answer those operational questions.

Pay particular attention to failure states. What happens after a timeout, when a record already exists or when approval is later withdrawn? Retrying an operation must not silently create another notification or an incorrect assignment. Make the intended business handling visible before planning a larger migration.

The GOV.UK integration guidance emphasises the relationship with existing infrastructure, skills and support. Our working model translates that into a specific task: test a connection using the data shapes and workflows actually required. An isolated product demonstration cannot substitute for that exercise.

Name an owner at every system boundary. If the product supplier and extension developer each point to the other, the unresolved operating problem stays with the customer. Establish a reviewable route for investigation and identify what evidence can be supplied without unnecessarily distributing business data.

7. Distinguish supported configuration from difficult modifications

A supported custom field is different from editing a product's core. Ask whether an adjustment uses the mechanisms the product supports. Have someone demonstrate how it is backed up, transferred and checked after an update. A working setting without a recovery route still presents an operational risk.

A small boundary description helps with an extension: what does it receive, what does it return and which versions does it support? Include a suitable error state and a test that can be repeated after a change. This prevents the full business behaviour from having to be rediscovered after every small update.

A custom application also needs controlled dependencies. It may rely on libraries, databases and external services. Custom therefore does not mean independent of every other producer. The important question is whether the component inventory, maintenance ownership and necessary transitions are documented. A long dependency list without assigned maintenance is not an advantage.

The NCSC secure-development guidance addresses development practices and third-party components, among other topics. Our comparison does not turn that into a certification scheme. For each option, it asks for named responsibilities, maintainable components and reviewable processes rather than accepting a general promise of security.

8. Compare costs only among suitable options

An option that cannot satisfy an essential task does not become suitable through a lower price. In the fictional example, one simple standard configuration leaves the shortlist because it cannot adequately represent the required approval. An extended product and a separate application remain for further assessment.

This is not a general argument against off-the-shelf software. Another product or a differently shaped workflow could meet the same requirement. The rejection concerns only the examined option in its documented state. Preserve that limitation so that one experience does not become an unsupported judgement about a whole product category.

Then compare the same horizon and tasks. Initial work can include setup, migration, clarification and introduction. Operation includes recurring services, support and internal effort. A later export or transition may also consume resources. Give a custom application the same complete lifecycle treatment as a purchased product.

Keep uncertain inputs visible. The effort required for an extension may be difficult to estimate before technical investigation. A small bounded exploration can be more useful than prematurely commissioning the complete solution. Give that exploration a specific question, deliverable, time window and effort limit so it reduces a decision-relevant uncertainty.

9. Evaluate usability through the actual workflow

The team must be able to use the system in ordinary work. Ask people with different responsibilities to carry out the same complete transaction. Observe questions, search paths and assistance. A fluent presentation by an experienced salesperson says little about how a new employee will handle the exceptional cases the organisation actually needs.

Distinguish unfamiliar interaction from a business obstacle. Another menu can be learned. A missing relationship or incomprehensible error can block the transaction itself. Record the observation and its effect instead of simply giving the interface a spontaneous grade based on appearance or personal familiarity.

Consider the working environment. Mobile access, keyboard navigation, enlarged text and slow connections may be decisive. Test the conditions the organisation needs. An attractive large display in a meeting room does not automatically cover them. Equally, a bounded selection exercise does not need every imaginable combination of device and connection.

Plan introduction as a real work package. It may need short instructions, representative exercises and a named contact for questions. Buying a product removes this effort no more reliably than commissioning development. The simpler option is the one that makes the required workflow understandable with appropriate support.

10. Check a small selection model with JavaScript

The following teaching function checks one formal condition of our working model: every essential requirement must have a successful controlled test at evidence level three. It assesses neither the quality of that test nor security or privacy. Inputs are fixed data under our control, not unchecked public user submissions.

const requirements = [
  { id: 'approval', required: true },
  { id: 'customerSeparation', required: true },
  { id: 'export', required: true },
  { id: 'colourChoice', required: false }
];

function unresolvedRequirements(requirements, evidence) {
  return requirements
    .filter(item => item.required)
    .filter(item => {
      const result = evidence[item.id];
      return result?.level !== 3 || result?.passed !== true;
    })
    .map(item => item.id);
}

const option = {
  approval: { level: 3, passed: true },
  customerSeparation: { level: 2, passed: true },
  export: { level: 3, passed: true }
};
console.log(unresolvedRequirements(requirements, option));
// ['customerSeparation']

A demonstration of customer separation is not yet sufficient in this example. The open point disappears only after a successful controlled test. Missing evidence and an explicitly failed test also remain unresolved. Optional colour choice does not affect the result because it is not an essential requirement.

Keep the actual test report alongside the formal status. Include conditions, data, expectations and observations. Otherwise the “passed” field becomes just another unsupported promise. The function helps maintain an overview, but it cannot assume professional responsibility for the information entered into the model.

11. Examine handover and transition before deciding

Ask each suitable option to demonstrate a small data export. It should contain the necessary relationships and understandable descriptions as well as files. Check whether another person can reconstruct the context from a sample. “Export available” is weaker evidence than an actual attempt to reuse the exported information.

For custom development, appropriate source files, build instructions and operating information belong in a suitable handover. The applicable rights and obligations depend on the specific agreement and are not legally assessed here. At selection stage, establish whether the promised handover can be described practically and verified.

For an existing product, examine formats, available transition routes and supported extensions. Configuration also needs understandable documentation. Otherwise a product change can fail because crucial knowledge exists only in individual people's heads. A named future owner therefore matters just as much as an export button in the interface.

Checklist for a reviewable software decision

• Describe the complete business transaction and the scope boundary.
• Separate indispensable outcomes from design preferences.
• Distinguish direct use, configuration, extension and separate development.
• Use the same relevant test cases for every option.
• Record evidence level separately from a successful result.
• Consider interfaces, retries and failure states.
• Clarify maintenance ownership for the product and extensions.
• Observe use under the conditions the team actually needs.
• Include introduction, internal effort and operation.
• Try a representative export and handover.
• Record the decision with its limitations and unresolved conditions.

Common questions about selecting software

When is an existing product a strong candidate?

When its workflow reliably covers the essential tasks and necessary changes remain within supported mechanisms. Still examine introduction, migration and ongoing support. A popular category is not evidence that a particular configuration will meet your requirements in the actual operating environment.

When can custom development make sense?

When suitable existing options cannot reasonably cover the decisive business workflow and both development and long-term operation are organised. The justification needs concrete tests. A general desire for unlimited freedom explains neither the scope nor the maintenance responsibility.

Is a combined approach automatically the best compromise?

No. It can close a specific gap, but it can also add interfaces and unclear ownership. Describe the boundary, test its failure cases and establish shared support. A small extension helps only when it makes the overall operation more understandable or more suitable.

What should exist at the end of selection?

A concise reasoned decision, the common requirements, documented evidence, open conditions and a complete effort view. These should explain why the selected option fits the need. A long feature comparison without your own test evidence does not fulfil that purpose.

Sources and next steps

Sources checked on 9 November 2026. The primary sources explain broader principles. The document portal, test cases, evidence scale and JavaScript are original teaching models for this article, not assessments of actual products.

• GOV.UK: Define your purchasing strategy
• GDS: To build or to buy
• GOV.UK: Integrate and adapt technology
• NCSC: Secure design and development