Custom software or off-the-shelf: deciding what fits
Compare configuration, packaged software, integration and a custom build using real workflows, hard constraints and evidence from a trial.
Buy or configure software when it can support the required work well. Consider a custom build where a material part of the operation cannot be handled adequately by available products, or where several systems need a purpose-built workflow between them.
The decision should follow evidence from real scenarios. A general preference for buying or building is a weak basis for choosing a system the business may depend on for years.
Describe the gap before comparing products
Map how a real job moves from request to completion. Include approvals, exceptions, integrations and the information users need at each handover. Show the side spreadsheets and inboxes that currently hold the missing steps.
Distinguish an essential requirement from a familiar habit. Some steps deserve to change when better software is introduced. Others protect a customer commitment, regulatory requirement or operating advantage that a standard product must not remove.
Define the result you want to improve: fewer missed handovers, more visible status, less repeated entry or a shorter completion time. Keep these measures available when a demonstration introduces attractive features unrelated to the problem.
Test four realistic directions
| Direction | Useful when | Main trade-off |
|---|---|---|
| Retain and improve the process | The gap is contained and the current system remains suitable | Manual effort and dependencies need to stay visible |
| Configure an existing platform | Supported settings can model the work clearly | Configuration needs ownership and controlled change |
| Buy a packaged product | Your requirements fit a maintained product and its interfaces | You accept its boundaries, roadmap and exit terms |
| Build or integrate | Important workflows remain unsupported or span systems | You need product ownership and sustained engineering support |
A mixed approach is often worth testing: retain the reliable finance or operational core and build only the part that cannot be covered well through configuration or a supported product.
Use the same evidence for each option
Check hard constraints before scoring preferences. These may include access controls, required interfaces, information handling, record export and the capacity to support the system after launch.
Then compare shortlisted options against the same representative scenarios. Ask users to complete the ordinary path and an awkward exception. Record what works, what requires configuration and what still needs a workaround.
An optional comparison sheet can use these criteria:
- Fit to the essential workflow and exceptions.
- Ability to connect with systems that must remain.
- Information control, permissions and auditability.
- Effort to implement, train, support and change.
- Portability of data and continuity if the supplier changes.
Agree any weights before the demonstrations. Treat the score as a record of your judgement, not a validated threshold that can select the right product automatically.
Keep a short comparison sheet with the same columns for each option: requirement, importance, demonstrated evidence, remaining gap, action and owner. For example, “an approver can return an incomplete request with a reason” is testable. “Flexible approvals” is too vague to support acceptance.
Distinguish capability from readiness. A feature demonstrated in a vendor's sample environment may still need configuration, data preparation and training for your business. Record that effort in the comparison instead of treating the demonstration as a completed implementation.
If a build is needed, define how it will be controlled
Discovery should test the assumptions the plan depends on: workflow fit, external access, data quality and difficult rules. Its outputs should support a decision to proceed, narrow the scope or stop.
Write down the scope, exclusions, acceptance criteria and decision rights. A material change needs an assessment of its effect on timing, testing and other work. Agree support responsibilities and release conditions before deadline pressure makes those discussions harder.
Have the agreement address code, data, documentation, licences for pre-existing components and an exit process. Confirm the legal terms with the relevant advisers rather than assuming payment establishes ownership of everything delivered.
Use client work as evidence of fit
Twin Global's ScriptStream work illustrates a custom platform connecting specialist roles and Australian digital health services. BOP Plus owns the product; Twin Global developed it. It is an example of a particular delivery scope, not a claim that custom software is always preferable.
For your own decision, keep the comparison tied to the workflow that must improve. If a supported product meets it, a build needs a clear additional reason. If no product does, the proposal should explain exactly what will be built, how it will be accepted and who will own it in operation.