Configure, Integrate or Build: Choosing the Smallest Software Change
Compare configuration, integration, a custom component and replacement against one verified constraint, including maintenance and exit costs.
Updated September 9, 2026
Decision briefing
A workaround is annoying. It is not, by itself, a reason to replace a platform. Before commissioning custom software, identify what the current system cannot do, why configuration or integration will not resolve it, and what the proposed replacement would make the business responsible for.
For an industrial supplier, the constraint might be product-family routing, distributor access or preserving technical context between an enquiry and CRM. Those are specific requirements. “We need a modern stack” is not.
Make the constraint reproducible
Show the current workflow and the point where it fails. Retain examples, affected roles and relevant configuration. Ask whether the limitation belongs to the software, its setup, the data or an unresolved process.
If regional sales and engineering disagree about ownership, replacing the CRM will not settle the disagreement. If an agreed routing rule cannot be represented or integrated reliably, there may be a genuine platform constraint to address.
Consider the smallest change first
| Option | Reason to choose it | Question before approval |
|---|---|---|
| Keep and configure | The platform supports the requirement without fragile workarounds | Has a knowledgeable administrator tested the configuration? |
| Integrate | The missing capability exists elsewhere and the data boundary is clear | Who owns failed synchronisation and duplicate records? |
| Add a custom component | One bounded task needs a specialised interface or rule set | Can the component fail without disabling the whole journey? |
| Replace | Structural limitations repeatedly block important work | Are migration, operating ownership and exit costs funded? |
Custom software changes the dependence
Custom software can create dependence on a maintainer, hosting platform, framework, integration or contract. Ownership of a code repository does not establish ownership of every dependency or the ability to operate the system independently.
Ask who owns the intellectual property, where the code and deployment instructions live, which services require ongoing payment and whether another qualified team could take over. Check export formats and whether the buyer can obtain usable data without the original developer.
Packaged software carries different obligations: licence terms, available APIs, upgrade compatibility and vendor direction. Compare those specifics. “No lock-in” is too broad for either option.
Build a cost comparison without invented savings
Use the same planning horizon and workload assumptions for each option. A three-year worksheet can be useful, provided uncertain figures are marked as estimates and recurring costs are not omitted.
- Initial work: configuration or build, migration, integration, testing and training.
- Operation: licences, hosting, support, maintenance, monitoring and internal administration.
- Change: product updates, new territories, altered workflows and dependency upgrades.
- Exit: data export, transition support, replacement integration and parallel operation.
Keep time saved separate from cash saved. Releasing an engineer's time may be valuable without reducing payroll. State how that capacity would be used and what evidence supports the estimate. A precise spreadsheet is not necessarily a reliable business case.
Test the migration before committing the whole business
| Option | Initial | Annual operation | Exit provision | Total |
|---|---|---|---|---|
| Configure | 2,000 | 1,000 | 1,000 | 6,000 |
| Integrate | 8,000 | 3,000 | 2,000 | 19,000 |
| Custom component | 15,000 | 4,000 | 3,000 | 30,000 |
| Replace | 35,000 | 7,000 | 5,000 | 61,000 |
Total is initial work + three years of operation + exit provision. These alternatives are comparable only if they meet the same requirement; a cheap configuration that cannot preserve account permissions is not a viable option. If the component needs EUR 8,000 rather than EUR 4,000 annually, its total becomes EUR 42,000. Include internal administration and support in your own estimates, and show which costs are shared with the existing platform. The cost worksheet keeps these assumptions visible.
Take one bounded workflow and a permitted sample of data. Define the minimum behaviour that must survive: attachments, account relationships, ownership, history and permissions. Test export as well as import.
For an illustrative RFQ component, acceptance might include preserving the original attachment, preventing duplicate CRM records after a retry and routing an unresolved account match to review. Passing the happy-path demo would not be enough.
NIST's SSDF is relevant to development and maintenance discipline, not proof of the financial case for custom software. Keep security review, operating economics and workflow acceptance as separate checks.
Approve the option that removes the verified constraint with an operating burden the business can sustain. Sometimes that will be custom work. Sometimes it will be a configuration change that never appears in a redesign announcement.
Sources and scope
Does custom software remove lock-in?
No. Dependence can remain in hosting, licences, contracts, integrations and maintenance expertise. Check ownership and the practical ability to transfer operation.
When is a custom component preferable to replacement?
When a bounded requirement cannot be met sensibly through configuration or integration, and the business can own the component's maintenance and failure handling.
Solve the constraint without buying unnecessary change.
ShiftNode can determine whether the verified constraint needs configuration, integration, a focused custom component, or no rebuild at all.
Talk to ShiftNode