Decision guide · Ireland · updated 12 September 2026
Custom software vs off-the-shelf: what should you keep, configure, integrate or build?
For most Irish SMEs, the useful decision is not simply buy or build. Keep a maintained system when it supports the operation; configure a standard product when setup closes the gap; integrate useful tools when their handover is missing; and build only the valuable, stable part that remains unsupported.
These options are not mutually exclusive. Automation may be an existing feature, a configured rule, a cross-system flow or part of a custom component. This guide is for operations leaders in B2B companies of roughly 10–100 employees and does not replace checking the actual product, plan, contract, data access and support arrangements.
Written by Intelidatia · Spain-based software partner serving Ireland remotely
A practical decision tree
Start with one bounded workflow, not a list of desired features. Name where it begins, what a successful end looks like and who is responsible for the result. Then follow these questions.
- Is the current process understood and owned?
No: keep the current tools temporarily and map the normal path, recurring exceptions, owners and current evidence of delay or rework. Buying or building now would lock assumptions into a system. Yes: continue.
- Does the current system support the full workflow, including important exceptions, permissions and reporting?
Yes: keep it and improve adoption, data quality or operating instructions. Mostly: examine configuration. No: locate the gap inside one tool, between tools or in a missing capability.
- Can supported configuration close the gap?
Check fields, roles, views, approval rules, notifications, templates and reports under the organisation’s actual plan. Yes: run a bounded configuration trial, assign an owner and test exceptions. No: continue; an unsupported workaround is not reliable configuration merely because it can be assembled.
- Is the unresolved problem a handover between systems that should remain?
Yes: assess integration. Confirm authority for each record, permitted access, matching and what happens when transfer is late, rejected or uncertain. No: continue.
- Does a necessary part of the operation remain unsupported?
No: keep the maintained tools, configuration and integrations. Yes: continue.
- Is the remaining workflow valuable, repeated, sufficiently stable and owned?
No: simplify or stabilise it; a documented manual step may be safer. Yes: scope the smallest useful custom component, how it coexists with retained tools, who operates it and who maintains it.
Each branch should end in a testable next action: improve current use, run a configuration trial, verify an interface with representative data or scope a bounded custom phase. “We need digital transformation” is not a decision.
Compare the four approaches
| Decision factor | Keep | Configure | Integrate | Build |
|---|---|---|---|---|
| Process fit | The current workflow already reaches the required outcome. | A common process is covered once supported settings close the gap. | Each tool fits its part, but the handover does not. | A valuable remaining workflow is genuinely specific. |
| Exceptions | Rare exceptions can be handled safely. | Important exceptions can be represented and tested. | Exceptions mainly concern transfer, matching or timing. | Recurring exceptions need unavailable rules or interfaces. |
| Responsible owners | Process and system owners remain necessary. | An administrator owns configuration and changes. | Someone owns failures and reconciliation. | Product, operational and maintenance ownership continue after launch. |
| Permissions | Existing controls match real responsibilities. | Roles work under the organisation’s actual plan. | Access is checked at both ends and for the connection account. | Least-privilege roles and administration enter the scope. |
| Data access | The team can retrieve the records it relies on. | Exports, interfaces and restrictions are verified first. | Read/write operations, identifiers and limits work at both ends. | The data model, imports, exports and retained-tool boundaries are defined. |
| Maintenance | The team owns use, access, data quality and vendor management. | Administration and retesting after changes are planned. | Monitoring, credential changes, failures and vendor changes are owned. | Hosting, security updates, support and evolution are planned. |
| Provider exit | Essential history can be retrieved. | Configuration, ownership and migration options are documented. | The connection can be operated and replaced without hidden knowledge. | Code, documentation, data export, credentials and handover are agreed. |
| Time to useful result | Immediate if the underlying process works. | Often suited to a bounded trial. | Depends on access, data quality and both systems. | Requires discovery and phased delivery before the first useful release. |
| Total cost | Licence, administration, training, workarounds and switching risk. | Licence tier, setup, administration, training and future changes. | Retained licences, implementation, monitoring, recovery and support. | Discovery, delivery, hosting, maintenance, support, change and transition. |
| Becomes insufficient when | A material workflow cannot be completed or controlled. | Critical roles, exceptions or data access remain unsupported. | The missing capability is not a transfer problem. | Value does not justify ownership or the process is too unstable. |
Off-the-shelf is not a single option: default use differs from extensive configuration and several integrations. Custom software need not replace every tool; it can be the smallest missing part of a wider system.
Eight criteria to decide with evidence
1. Fit the real process, not the ideal diagram
Test one normal example and several awkward ones: a revised request, missing information, an absent owner and work returning to an earlier stage. A strong fit avoids hidden spreadsheets, shared passwords and repeated re-entry. If the central issue is a decision moving between owners, map the approval before choosing a tool.
2. Count exceptions before features
Record how often the standard path breaks, who resolves it and what information they need. Rare, low-risk exceptions may remain manual. Frequent or consequential exceptions need an explicit home in configuration, an integration flow or a custom component.
3. Name the responsible people
Name owners for the process, system access, data quality and change approval. Integration adds responsibility for failed or uncertain transfers; custom development adds product and ongoing funding responsibility. Software will not create missing ownership.
4. Test permissions with real roles
List who may view, create, change, approve, export and administer information, then test representative accounts. Do not assume a role described on a product page is included in the organisation’s plan. An internal tool is relevant only when existing permissions or interfaces cannot express the required workspace.
5. Verify access to the data
Inventory important fields, the authoritative system, stable identifier, required history and acceptable delay. Verify current export and interface options in provider documentation, the contract and a representative account. If data movement is the central issue, use the software integration guide to examine ownership, validation and recovery.
6. Plan maintenance before launch
Assign user access, configuration changes, incidents, vendor changes, documentation and support. Integrations require monitoring and recovery; custom systems also require hosting, updates and a route for prioritising change.
7. Make provider exit a designed scenario
Identify the usable exports, configuration records, interface documentation, administrator access, code or deployment information and handover period needed if a product or partner changes. The appropriate package depends on the option and contract.
8. Compare total cost, including work that remains
Total cost = licences + setup or delivery + internal administration + training + integrations + support and maintenance + residual manual work + expected transition cost.
Keep uncertainty visible. Do not turn unverified time savings into guaranteed return. If manual effort is material, first estimate the cost of the current process and state the assumptions separately.
When each option is reasonable — and when it is not enough
Keep the current system
Reasonable when: The workflow reaches the required result; controls and data access are adequate; the main issue is inconsistent use, unclear ownership or poor data discipline.
Insufficient when: A material part cannot be completed or controlled, or evidenced workarounds create recurring delay, error or risk.
Configure standard software
Reasonable when: The workflow is common, settings cover important roles and exceptions, and a named administrator can own changes.
Insufficient when: A critical rule or permission is unsupported, workarounds become opaque or necessary data cannot be accessed reliably.
Integrate existing tools
Reasonable when: Each tool remains useful, the gap is their handover, and both sides provide suitable, permitted access.
Insufficient when: No system has clear authority, the operation is unsupported or the real gap is a missing workspace or decision process.
Build a custom solution
Reasonable when: A repeated, valuable workflow remains unsupported, its boundaries and owners are clear, and the organisation can fund operation as well as delivery.
Insufficient when: The need is a commodity process, rules cannot be bounded, no one owns the outcome or the case depends on unobserved savings.
For the final option, see custom software capabilities. Intelidatia designs and builds custom systems around real operations, delivered remotely from Spain. Custom development is one possible conclusion, not the predetermined answer.
A synthetic B2B example: enquiry to completed job
Illustrative example — not a delivered client project. Consider an Irish B2B service company with 35 employees. Its customer-management system holds organisations and opportunities, a shared spreadsheet schedules approved jobs, and accounting software creates invoices. Operations wants clearer control from accepted quote to completed work.
- Keep: retain customer-management and accounting systems because each serves a defined purpose.
- Configure: add a job reference, delivery owner and “approved for scheduling” state if the organisation’s actual product and plan support them. Test a revised quote and absent approver.
- Integrate: if approved job details still need copying, assess a controlled handover. Decide which record owns the reference, scope, date and status; make rejected or uncertain transfers visible.
- Build: if standard scheduling products cannot represent recurring constraints that materially affect delivery, consider a focused operations workspace. Keep invoicing in the accounting system and pass back only agreed completion information.
Automation can support every stage. If current scheduling handles the constraints, keep or configure it. If the only repeated problem is copying approved data, integrate. Build only if a valuable capability remains unsupported and the company is ready to own it.
What to gather before asking for a proposal
Bring enough evidence to discuss the workflow without sending customer records, passwords or production credentials:
- the start and successful end of one bounded process;
- a normal recent example described without personal or confidential data;
- three to five recurring exceptions and how often they occur;
- the roles involved, decision owner and owner of each next action;
- current tools, plan or edition where known, and the purpose of each;
- important records and their authoritative system;
- current export and interface documentation, plus known access restrictions;
- permission needs for staff, managers, partners and administrators;
- evidence of manual touches, re-entry, waiting, correction or risk;
- expected process changes during the next year;
- support expectations, administration capacity and provider-exit needs;
- budget range, decision date and the smallest useful result.
This lets the team compare a configuration trial, integration assessment and custom first phase on the same operational basis.
Turn the comparison into a scoped decision
If you have one workflow but are unsure which option fits, describe where the work starts, the tools involved, the people responsible and the point where it breaks. Do not include customer data or credentials.
For a complex or unclear process, the next step may be the Operational Workflow Sprint, which maps the operation and makes the keep, configure, integrate or build decision explicit before a development proposal. Review that page for the current scope, price and exclusions.
Intelidatia’s published project evidence relates to organisations in Spain. You can review those projects to assess demonstrated system-building capability; they are not Irish client results or proof that a particular tool, connector or workflow will fit your operation.
Request a free 20-minute fit conversation