A SaaS product usually suits a standardised, low-risk process that is already covered by native features or reliable integrations. A custom internal tool becomes more appropriate when the process contains specific rules, frequent exceptions, critical data or an operational advantage that generic software cannot represent cleanly. Many Belgian SMEs should choose a hybrid approach: keep SaaS for ordinary functions and build only the differentiated part of the workflow. To decide, assess each process for complexity, personalisation, vendor dependence, expected evolution and business criticality. Then compare the full cost of staying as you are, adopting SaaS or developing and maintaining a custom tool.
The right unit of decision is the process, not the company
A company rarely needs one answer for every department. Accounting may work well in a standard SaaS platform, while a project-specific approval workflow, operational portal or pricing calculation may require a different solution. Treating the choice as an enterprise-wide contest between SaaS and custom software often creates unnecessary cost or forces an important process into a poor fit.
Start with one real business journey and divide it into stages: data collection, validation, calculation, decision, execution, follow-up and reporting. Record who acts at each stage, which data is needed, which exceptions occur and where employees move information manually between tools.
This exercise reveals the nature of the process. A standardised process follows predictable rules and resembles how many other companies work. A differentiated process reflects your own method, commercial promise or operational advantage. A critical process can affect customers, cash flow, compliance or continuity if it fails. A process dependent on spreadsheets, email chains and repeated copy-and-paste deserves particular attention.
Begin with a practical question: which step consumes time or creates risk because no existing tool represents it properly? That step may be the right boundary for a custom internal tool, even if the rest of the workflow remains in SaaS software.
Custom internal tool or SaaS software: useful definitions
SaaS software is a service supplied and maintained by a software publisher. You use a shared product through a subscription or another recurring commercial model. Its features, data structures and release schedule are designed for a broad customer base, even when the product offers configuration options.
A custom internal tool is an application developed around your organisation's own process, rules, roles and data. It may be a web application, an operational dashboard, a portal or a focused layer connecting existing systems. Its value comes from fitting a particular workflow rather than reproducing every function of a large general-purpose platform. You can learn more about custom internal tools before defining a project.
Do not confuse four different activities. Configuration changes settings already provided by the SaaS product. Personalisation adjusts screens, permissions or fields within its supported limits. Integration connects the product to another system through an API, file exchange or connector. Specific development creates behaviour that the product does not natively support. A long list of workarounds does not necessarily mean you have achieved useful customisation; it may indicate that the underlying product is a poor fit.
The decision also concerns control. Ask who controls the data model, release timetable, recurring costs, security settings, integrations and exit conditions. A low initial subscription can become expensive if exporting data, replacing connectors or changing the workflow later is difficult.
The five criteria that shift the decision
Assess the same process against the following criteria. Do not score the entire company in one broad category. A process can be simple but highly critical, or complex without being strategically important.
- Complexity: Count rules, exceptions, approval paths, user roles and dependencies between stages. A SaaS product may remain suitable when its workflow engine expresses these conditions clearly. It becomes less suitable when employees must remember invisible rules or maintain parallel spreadsheets.
- Personalisation: Ask whether the process reflects a distinctive way of selling, delivering, calculating, allocating or controlling work. The more the process contributes to an operational advantage, the stronger the case for targeted development.
- Vendor dependence: Check API quality, export formats, data ownership, termination terms, price-change provisions and the availability of independent integrations. Dependence is manageable when the exit route is documented and technically practical.
- Ability to evolve: Consider how often the process changes and who must control the timing. A SaaS product is useful when its roadmap follows your needs. A custom tool is more attractive when new rules must be added without waiting for a publisher or creating workarounds.
- Criticality: Examine the consequence of an error, outage or data loss. Critical processes need tested access controls, backups, monitoring, recovery procedures and clear responsibility, regardless of whether the solution is SaaS or custom.
A comparison framework for a Belgian SME
The table below compares the three practical options for an SME with five to one hundred people. It is not a universal verdict. Use each question to compare actual products, suppliers and development proposals against the same process.
SaaS, custom internal tool and hybrid approaches compared for a Belgian SME.
| Decision area | SaaS | Custom tool | Hybrid | Question to ask |
|---|---|---|---|---|
| Time to start | Usually faster | Requires delivery | Focused delivery | Which part must work first? |
| Process fit | Shared model | Specific model | Specific core | Where do users leave the intended workflow? |
| Maintenance | Publisher-led | Owner-managed | Shared responsibility | Who fixes failures and updates? |
| Integrations | Connectors or API | Built to purpose | Several interfaces | Are interfaces documented and tested? |
| Data control | Contract and export dependent | Defined by project | Split across systems | Which system is the master record? |
| Future changes | Roadmap dependent | Under your control | Selective control | How will a new rule be introduced? |
| Supplier dependence | Publisher dependence | Developer dependence | Both | What happens if the supplier disappears? |
For Belgium, verify where personal and business data is hosted and processed, what role the supplier has as a processor under the GDPR, how access is controlled and how data is deleted or returned. Check support and interface language, invoicing in euros, VAT treatment, accounting exports and the systems already used by your accountant. Operations in Brussels or Wallonia may also require attention to language, local administrative workflows and the availability of suitable support.
Do not compare subscription prices alone. Include migration, configuration, training, connectors, additional user or storage charges, internal administration, workarounds, custom extensions and the cost of changing solutions. For a custom tool, include discovery, design, development, hosting, monitoring, maintenance, support, security updates and future changes. You can review Numinam's pricing information after clarifying the process and the expected scope.
The hybrid approach: SaaS as the foundation, custom software around the differentiator
A hybrid architecture is often the most proportionate answer. Keep ordinary functions in established SaaS products when they meet the need: accounting, email, document management, standard CRM, collaboration or routine scheduling. Build a focused internal tool for the part that coordinates approvals, applies specific calculations, provides an operational portal, consolidates information or connects several systems.
The architecture should have clear boundaries. Keep master data in the system best suited to own it. Avoid copying the same customer, product or transaction data into several places unless there is a defined reason. Document what each interface sends, when it sends it, how errors are handled and who can correct them. A small custom application that orchestrates existing systems can be more maintainable than forcing every process into one oversized platform.
Hybrid becomes a poor choice when the SaaS product has no usable API, synchronisations are fragile, records contradict one another or every new requirement produces another isolated extension. In that situation, calculate whether replacing the central SaaS product would be simpler than continuing to build around it. The signs described in When SaaS Is No Longer Enough for a Small Business can help structure that review.
A decision method before you sign or develop
- Map a real case from start to finish. List actors, inputs, outputs, exceptions, deadlines, approvals and current tools. Speak with the people who perform the work, not only the person buying the software.
- Calculate the cost of staying as you are. Include staff time, delays, errors, duplicate entry, missed information, spreadsheet maintenance and the operational consequences of an interruption.
- Calculate the total SaaS cost over a defined decision period. Include licences, setup, migration, training, integrations, support, price-change exposure and the cost of limitations.
- Calculate the total custom-tool cost over the same period. Include discovery, delivery, hosting, backups, monitoring, maintenance, support, security and likely changes. Before launching custom software development, clarify ownership, responsibilities and acceptance criteria.
- Test SaaS with normal scenarios and exceptions. Request a hands-on trial or structured proof using your own workflow. Ask the supplier to demonstrate failed validation, rejected approvals, amended records, exports and recovery rather than only the ideal path.
- If custom development is selected, define a narrow first release. Specify the users, process boundary, data access, integrations, security requirements, maintenance arrangement, change process and conditions for transferring the application and data to another provider.
Before signing, ask the SaaS provider for a sample export in a usable format, the API documentation, deletion and retention procedures, backup information, service responsibilities and the contractual process for termination. A statement that you can export your data is less useful than knowing which records, attachments, history and relationships will actually be included.
The practical decision rule
Choose SaaS when the process is standard, its exceptions are covered, the integrations are reliable and the publisher's operating model is acceptable. Choose a custom internal tool when the process is specific, strategically useful or too critical to operate through workarounds, and when your organisation can maintain clear ownership. Choose hybrid when only one part of the workflow needs differentiation and the interfaces between systems can remain simple, documented and dependable.
The objective is not to own more software. It is to give each process an appropriate level of control. That may mean adopting a SaaS product without modification, replacing a spreadsheet with a focused internal application or connecting both approaches around a well-defined operational core.
