Business software buying guide
Custom software or an off-the-shelf tool?
An off-the-shelf tool makes sense when it already supports your core workflow. An integration is an option when good tools need to exchange data. Consider custom development when important business rules are not supported by existing products. Compare the decision with the cost of manual work, implementation and ongoing maintenance.
Compare three ways to solve the problem
Scroll horizontally to compare all columns.
| Approach | When to consider it | What to check first |
|---|---|---|
| Off-the-shelf software | The process is standard and the available features fit the team. | Licences, data export, user roles and the cost of changing your process. |
| Integration of existing tools | Individual tools work well, but data is copied between them. | APIs, permissions, supported actions, limits and failed-transfer handling. |
| Custom development | An important workflow has its own rules, approvals or working practices. | First-version scope, acceptance criteria, migration and post-launch responsibilities. |
When is custom software worth considering?
Start with one real workflow. Who enters a record, who reviews it and what decision comes next? If an existing tool can cover the process through configuration, a new application may be unnecessary. If important rules remain in spreadsheets and messages, assess the cost of building the missing part.
Rental billing is an example: equipment changes across customer locations during a month, while contract rates and periods must remain traceable. General invoicing software can stay as the destination, with a separate system recording changes and preparing the calculation.
What determines the cost of a business application?
Compare development, licences, integrations, data preparation, training and maintenance. The same feature name can hide very different work. ‘Document approval’ could mean one confirmation or several departments, substitute approvers, notifications and a record of changes.
For a useful estimate, prepare a workflow example, user roles and a list of systems. Ask for the first version, optional features and recurring costs to be separated. A price or delivery date given before data access is checked still rests on assumptions.
How can you start without replacing the whole ERP?
Choose a process that can be checked independently: a request portal, order transfer or a data view. Define which system is the source for each customer, item and document so the same record is not changed inconsistently in multiple places.
Before development, check test-environment access, a realistic data sample and what happens when a transfer fails. Automation needs a way for the responsible person to notice and resolve an exception.
What should you agree on ownership, security and maintenance?
The agreement should identify the code, licences, documentation and access being handed over. Agree who manages hosting and backups, who responds to problems and how the system can be taken over if the working relationship changes.
Include SSO, change logs, permissions and data-location requirements before the proposal. These need assessment and verification. Maintaining existing functionality and developing new capabilities should each have a clear agreed scope.
What should you send for an initial estimate?
- One end-to-end workflow and the people involved.
- An example document or an anonymised data record.
- The names of your ERP, CRM, accounting and other connected systems.
- Required first-version features and what can come later.
- Known timing, access and security constraints, and any budget range.
A finished specification is not required for the first conversation. A description of real work is more useful than a long feature list without context.