Standard software or a custom application: compare the work that needs doing

Start with the difficult operational decision

A wish list often begins with visible frustration: too many spreadsheets, unclear progress or information spread across applications. Ask which decision is delayed as a result. Does a planner need to know whether an enquiry is complete, or should a customer be able to request a change? These questions separate an essential outcome from one possible presentation of it.

A fictional rental business initially asks for a new booking system. Discussion reveals that unusual collection times are the main problem. The current product already handles availability and invoicing adequately. Discovery therefore becomes narrower: demonstrate how exceptional collection arrangements can be recorded and found without replacing the entire administration. That is a more testable problem than the original product request.

GOV.UK Service Manual: How the discovery phase works ↗

Give every candidate the same trial

Provide each candidate with the same starting information, normal request and awkward exception. Show which person performs each step and what information should exist afterwards. For a product, ask for an actual configuration or demonstrable trial instead of an assurance that a subject appears on a roadmap. Record any capability that the supplier still needs to investigate.

Assess a custom proposal against the same business outcome. A design need not be fully built before critical assumptions can be examined. A data model, interface prototype and focused technical experiment may provide useful evidence. Keep the standard of evidence comparable: judging one option on a promise and another on thoroughly exercised exceptions creates an unfair and misleading basis for the eventual choice.

Separate configuration, extension and process change

Configuring a product differs from changing it. Configuration uses existing rules and capabilities. An integration moves information between systems. An extension adds missing behaviour. Classify each proposed task, identify its owner and ask what must be checked after a product update. This makes a quotation more understandable than calling every piece of work a small adjustment.

Also investigate whether the problem belongs outside software. If staff disagree about when an enquiry is complete, adding another field does not create a common decision. Ask the process owner to define the criterion first. A small working-practice change might be sufficient, or might make the necessary software substantially simpler than the original feature list suggested to everyone involved.

Sometimes existing software mainly needs to work together better. Examine integration as an alternative: Standard connector or custom integration: test the whole process.

Identify where differentiation actually matters

Not every internal process justifies a custom application. An established working method can appear unique simply because it developed historically. Ask which difference provides demonstrable value to customers or staff. It might involve specific planning rules, access to proprietary information or a distinctive handover. Ordinary supporting functions do not automatically need to be rebuilt to enable that difference.

The rental company might need an exception planner while retaining standard accounting. Describe the boundary through concrete events: an approved arrangement is passed on, an invoice state returns. Investigate whether both applications can support those events dependably. This compares a focused combination with wholesale replacement, instead of presenting two extremes as the only choices a business could reasonably make.

Examine data and access before switching

A useful product must do more than display the right information. You need to understand how existing records arrive, how people and organisations remain identifiable and which exports are available. Request a sample of the actual transfer. Check meanings, references and attachments. Downloading a file does not establish that another application can interpret it without additional explanation or transformation work.

Define which roles may use which information. For a customer portal, viewing only an individual request differs from accessing an organisation-wide account. Trial two separate customers and a staff member with limited responsibilities. The final solution must enforce those boundaries regardless of the product name or development approach. Include exclusion cases, not just a demonstration by someone with administrator access.

Compare total work in your own scenario

Base estimates on genuinely offered terms. Separate configuration, migration, integration, training, maintenance and recurring usage. Include staff effort that remains in double entry, exceptions and review. A cheaper subscription may involve more manual work, while a more expensive design may include capabilities your organisation does not need. Comparing the whole working arrangement makes those tradeoffs visible.

Choose a normal period and a period of peak demand. Distinguish measured volumes from assumptions. Do not automatically count freed capacity as a reduction in expenditure. Explain what staff can do with the time and when that produces business value. A calculation becomes more useful by exposing its conditions than by presenting an apparently precise final amount unsupported by the current evidence.

Ask who can assess future change

A product supplier controls parts of product development. Custom software leaves more responsibility with the customer and development team. Both arrangements need somebody who can prioritise requests and assess consequences. Investigate how a change is proposed, what requires discovery first and who may decide that the current solution is sufficient for now instead of approving another development phase.

Discuss one realistic future request. The rental company might add another location with different opening hours. Which existing records and rules would change? An answer explaining dependencies is more useful than a broad promise that expansion is always easy. You need not buy that extension now to understand its important boundary and make a more informed initial choice.

Make operation and availability concrete

Ask what keeps the solution usable: changing accounts, reviewing updates, responding to alerts and restoring information. Establish which tasks the supplier performs and which remain with your organisation. A support arrangement becomes comparable only when the actual response commitments, included work and exclusions are clear. Product ownership alone does not explain how a busy team should handle an interruption.

Define behaviour that matters to users, such as an enquiry becoming visible within an agreed window. Google SRE distinguishes measured indicators from selected service objectives. Use that distinction as a thinking aid and choose proportionate criteria of your own. A small internal planner and a heavily used customer portal have different needs; a universal availability percentage does not replace examining those needs.

Google SRE: Service Level Objectives ↗

Investigate how you could leave later

Before choosing, ask how records, accounts and relevant documentation would be transferred. Product exports and commercial terms may affect a later switch. For custom software, source access, build instructions and knowledge concentrated in one developer can matter. Describe the technical handover you want, and have commercial or legal arrangements separately assessed where necessary rather than assuming a general ownership phrase resolves them.

Make exit practical with a small export and an explanation by someone other than the original maker. Can that person understand a record, attachment and status? Are references and selection rules explained? This examines transferability as a real activity. A broad claim about ownership or open standards says little about the work your own organisation might actually need to perform when changing its approach.

Record the decision and unresolved assumptions

Finish the comparison with the chosen first step, the principal reasons and assumptions still needing investigation. Record why alternatives are less suitable at present. That prevents the next discussion from restarting every original wish. Keep the trial cases and observed limitations so later extensions can build on the same understanding of the process rather than silently redefining it.

A sensible decision might be to investigate one uncertain integration or clarify a working rule first. Give that activity a concrete output and decision point. This keeps investment proportionate to the business problem. Completeness is not the objective in itself; the aim is a demonstrably useful next step for the people who will operate the eventual solution every working day.

Turn the explanation into a project decision

Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.

• Custom software development ↗
• Customer portal development ↗

Questions about this topic

Continue with a related question