Published on 26/09/2026
Off-the-shelf software, integration or custom development?
An order starts in an inbox, moves into a spreadsheet, and is typed into industry software later. Everyone knows the routine, but nobody likes it. A custom application can sound like the obvious answer. Yet there are three realistic options: configure software you already have, connect suitable systems, or build something specifically for your business.
The right choice does not begin with a product demonstration. It begins with the bottleneck you want to remove.
Define the problem first
Describe one process from trigger to result. Avoid "digitalize our administration". Write something testable, such as: "Once a purchase is approved, it should appear in the order overview without being retyped." Record who is involved, which data is required, which exceptions occur, and how you recognize a correct result.
Then examine the options in this order:
- Configure: Can an existing system handle the process with fields, templates, roles, or built-in rules?
- Integrate: Can two otherwise suitable systems exchange data through a documented interface?
- Build: Is there still an important operational gap that configuration or a dependable connection cannot close?
This order is not an absolute rule. It does stop an expensive development project from recreating a setting that was already available.
A buyer's decision table
| Question | Configure | Integrate | Custom development |
|---|---|---|---|
| Does the core process already fit? | Yes, mostly | Partly in each system | No, or only with serious workarounds |
| Where is the unusual requirement? | Fields, roles, or templates | The handover between systems | The working process itself |
| Who maintains it? | Vendor plus internal administrator | Both vendors plus an integration owner | Your business plus a development partner or internal team |
| Typical change risk | Vendor changes the product or plan | An API or data structure changes | Requirements, technology, and operation are your responsibility |
| What enables an exit? | Tested export and replacement route | Disconnect safely and retain data in both systems | Source code, documentation, access, and usable data formats |
Mark the statement that best matches your situation in each row. A majority in one column is a useful signal, not an automatic verdict.
When custom development is difficult to justify
A custom product rarely makes sense when it would replace a common process such as bookkeeping, appointment booking, or ordinary stock control without distinctive requirements. Established products spread development, bug fixing, and security work across many customers. One small firm would otherwise fund that responsibility alone.
An unclear or constantly changing process is another poor starting point. Software makes decisions explicit. If nobody can yet agree when an order counts as approved, new code will not remove the ambiguity. Simplify the process and test it with a small, reversible method first.
Finally, "no monthly license" is not a business case by itself. Custom software still creates recurring work: hosting, monitoring, updates, backups, support, new devices and browsers, and changes in connected systems.
Make total cost visible
Do not compare only a subscription with a project quote. For every option, estimate the same categories over a useful planning period:
- setup, migration, and training
- licenses, hosting, and external services
- internal administration and support time
- interface maintenance and updates
- fault investigation and user support
- export, handover, or migration on exit
An integration may retain subscriptions to two products and still cost less than rebuilding them. Conversely, a tailored application can become reasonable when one stable, central process hits the same costly limitations every day. The comparable total commitment matters more than the most attractive single number.
Ownership is more than source code
Before commissioning a custom application, establish in writing what you receive. Consider source code, usage rights, technical documentation, access to hosting and external services, an export in an understandable format, and instructions for operation and recovery. Also decide who applies security updates, prioritizes defects, and approves changes.
The same questions apply to an integration on a smaller scale. Who notices when a transfer stops? Are failed records retried? Can someone trace an error without calling the original developer first? A connection is an operational component in its own right and needs a named owner.
Prove one important assumption early
Test the riskiest assumption before committing to the full project. For off-the-shelf software, this might be a configured trial using realistic but non-sensitive data. For an integration, run one successful record and one invalid record through the connection. For custom development, a limited prototype can test the interaction and workflow logic. A prototype produces learning; it does not prove secure, reliable production operation.
You should eventually be able to complete this sentence: "We chose this option because it solves the defined bottleneck at an acceptable total commitment, and we know how to operate or leave it." If you cannot, the buying decision is not ready.
If you want to compare configuration, integration, and custom development for a real workflow, DevSeal can help through software and web services for small businesses.