Custom software or an off-the-shelf solution (SaaS)?

According to Mesterséges Intelligencia Központ Kft., a software development company based in Budapest, Hungary, off-the-shelf software (SaaS) is enough when it covers your processes; custom software pays off when you work differently or the software itself is your edge.

In short: If a ready-made product covers most of your processes without development, and the company can adapt to it, the off-the-shelf solution is the faster route. If you work differently from what ready-made products are built for, many systems must be connected, or control over the data and further development is a strategic question, custom development pays off. Often the right answer is both: a ready-made core with custom additions.

What do custom software, off-the-shelf software and SaaS mean?

The three terms answer two different questions: who the software was made for, and how it reaches the user.

Custom software: a program developed to order for the needs of one company. It does what the client asked for in the specification, the way people there work, and the client also decides where further development goes.
Off-the-shelf (boxed) software: a product made for many customers, which the company licenses and typically installs and runs on its own computers or servers. It can be shaped through settings, but the logic of how it works is set by the vendor.
SaaS (Software as a Service): off-the-shelf software that the vendor runs in its own cloud, while the company uses it on a subscription, in a browser or through a programming interface. A programming interface (API, application programming interface) is the connection point through which two programs exchange data without human involvement.

According to the cloud definition of the US National Institute of Standards and Technology (NIST), with SaaS the user uses the provider's application running in the cloud and does not manage the underlying infrastructure (network, servers, operating systems, storage) or even individual application capabilities, apart from limited user-specific configuration settings (NIST SP 800-145). This is both the strength and the limit of SaaS: the vendor takes the burden of operation off the company's shoulders, but it also decides what changes in the product, and when.

The third way: a ready-made core with custom additions

The decision is rarely “either–or”. For many companies the workable route is to keep the ready-made product for standard tasks such as accounting, email and office work, and to develop custom software where the company really works differently from others. The most common forms of the hybrid solution:

Integration: a custom program connects the off-the-shelf systems through APIs or webhooks, so data no longer has to be copied by hand. A webhook is an automatic notification that one system sends to another when an event occurs, for example when a new order arrives.
Custom module: an application of your own is built next to the off-the-shelf system for a process the product does not cover, for example a specific pricing rule, production scheduling or an industry-specific register.
Your own interface on top of the off-the-shelf system: customers or field staff get a simple interface tailored to their task, while the off-the-shelf system works in the background.

The advantage of the hybrid route is that the company only pays for development where something is genuinely unique. The drawback is that the custom parts have to follow changes in the off-the-shelf system's interface, so the integration needs logging and error alerts, and someone has to look after its maintenance. We write about connecting systems and automating repetitive work on the Process automation page.

Decision criteria in one table

Criterion	Leans towards off-the-shelf (SaaS) if…	Leans towards custom development if…
Fit with processes	the process is standard and the company accepts adapting to the software	the company works differently and wants to keep that difference
Competitive difference	the area does not set the company apart from competitors	the software itself is the business advantage, or carries it
Number of integrations	few systems need connecting, and ready-made connectors exist for them	many systems need connecting, or there are no ready-made connectors
Data and exit	the vendor offers a complete, machine-readable export and clear exit terms	the data model and control over the system are a strategic question
Users and licence model	few users and a predictable headcount	many or fast-growing users, where the per-user fee is decisive
Start-up speed	it has to work quickly, and the ready-made features are enough	the start can wait for development, or can happen in stages
Who maintains it?	there is no in-house IT capacity, and the vendor's maintenance is enough	someone can run it: an in-house team or a contracted developer
Data location and compliance	the vendor's data storage location and contract meet your requirements	data must stay in a defined place, or strict industry rules apply to it

Not every row has to point the same way. If most criteria lean towards the ready-made product, it is worth starting with that. If the heavy rows (fit, competitive difference and integrations) point towards custom development, it is worth planning in more depth and comparing at least one group of functions concretely.

What drives the total cost of ownership?

Total cost of ownership (TCO) is the outlay over the whole period the software is used, not just the price of getting started. The cost structure of the two routes differs, so comparing a single year can be misleading: look at the planned period of use.

With off-the-shelf software and SaaS, cost is typically shaped by:

the subscription, which often grows with the number of users and the chosen plan;
add-on modules and higher plans, if a feature you need is only available there;
implementation, configuration and training of staff;
integrations and customisation, often done by a separate partner;
exit: exporting and migrating the data if you ever have to switch.

With custom software:

development, which depends above all on the functional size of the software;
operation: hosting, monitoring and security updates;
maintenance and further development as the company's needs change;
retaining knowledge: documentation and the complete source code, so the system does not depend on a single person.

The cost of custom development can be planned when the scope is measured rather than estimated by feel. We measure the functional size of the development in COSMIC function points (ISO/IEC 19761), and the offer and the schedule are derived from it; the method is described on the Pricing page. Which route costs less in the long run depends on the number of users, how often things change and how many integrations there are. There is no general answer, only a calculation for the specific case.

Vendor lock-in and data portability

Vendor lock-in means that switching to another product is so difficult or costly that the company practically cannot leave. The cause can be a closed data format, an incomplete export, many settings tied to that one product, or a contract that is hard to terminate.

The European Union's Data Act (Regulation (EU) 2023/2854) has applied since 12 September 2025 and regulates switching between data processing services in a separate chapter; its recitals list SaaS among them. The text of the regulation requires, among other things (checked on 17 October 2026):

The switching terms must be set out in a written contract, and the notice period for initiating the switch may not exceed two months (Article 25).
On request, switching must be made possible without undue delay, within a transitional period of at most 30 calendar days, during which the service must keep running; if this is technically unfeasible, the provider may, with justification, set an alternative transitional period of up to seven months (Article 25).
The contract must list the data that can be ported exhaustively and provide a period of at least 30 calendar days for retrieving the data (Article 25).
From 12 January 2027 the provider may not charge for the switching process; until then only reduced charges are allowed, which may not exceed its costs directly linked to the switch (Article 29).

An important exception: the rule on charges and certain technical obligations do not apply to services whose main features have largely been custom-built for a single customer and which are not offered at broad commercial scale (Article 31). If the off-the-shelf system processes personal data on the company's behalf, the General Data Protection Regulation (GDPR) also binds the provider: at the end of the service it deletes or returns all personal data, at the choice of the controller (GDPR, Article 28(3)(g)). This is information, not legal advice.

The law improves the terms, but the exit is still for the company to plan, ideally when choosing. It is worth checking:

in what format all the data can be exported, for example as CSV (a comma-separated text file), JSON (a structured, machine-readable text format) or a database backup, and whether attachments, notes and the change log are included;
whether there is a documented API through which data can also be extracted continuously;
whether a trial export can confirm that the data loads into another system;
what the contract says about termination, switching charges and the deletion of data.

Who owns the source code?

With off-the-shelf software and SaaS, the company buys a right of use: the source code stays with the vendor, and the vendor decides the product's future, including new features, price changes and discontinuation. That is not a problem in itself if the product is stable and the data can be exported.

With custom development, the source code and the rights of use are settled by the contract, so it is worth stating explicitly who owns the code, whether the client receives the complete source code and documentation, and whether the system can be developed further by another developer. With us, too, the contract governs source code and usage rights. We cover the other important points of the contract in the article How to choose a software development company.

The weighing differs by type of system

The criteria above are general, but their weight differs by type of system. For enterprise resource planning, the trade-off between customisation and upgradability is the key question; see the article Custom ERP or a customised off-the-shelf ERP?. For customer relationship management, a distinctive sales process and per-user licensing matter a lot (see When is it worth developing a custom CRM?). For a webshop, the quick start of hosted platforms competes with freedom to extend, as discussed in Webshop: hosted platform or custom development?. You can read about business system development in general on the Business software page.

Decision checklist

The answers to these questions usually point the way on their own:

Can we describe the process in enough detail to check it item by item in a product demo?
How much of the process does the ready-made product cover through settings, without development?
Does this area set the company apart from its competitors, or does it work similarly in every company?
How many systems must it connect to, and are there ready-made connectors supported by the vendor?
How many users will work in the system in a few years, and how will the subscription change with that?
Do we get a complete, machine-readable export, and have we tried it with a trial export?
Where is the data stored and processed, and does this meet the company's data protection and industry requirements?
Who will run and develop the system further, and what happens if that partner drops out?
How much time is there until launch, and can the system go live in stages?

Typical mistakes

Comparing feature lists instead of the process: two products can promise the same feature; the difference lies in how it fits the company's daily work. Go through the demo with your own real cases.
Comparing only the first year's cost: the subscription grows with headcount, while the operation and further development of a custom system arise over the years.
Forgetting the exit: the data export has to be checked when choosing, not when terminating.
Too much customisation in an off-the-shelf product: beyond a certain point, upgrading a heavily customised off-the-shelf system takes more work than maintaining a well-separated custom module.
Replacing everything at once: a phased switch (one module first, then the next) is a smaller risk than one big, one-off change.

Frequently asked questions

When does it pay to develop custom software?

When the company works differently from what ready-made products are built for and wants to keep that difference; when many systems must be connected and there are no ready-made connectors; or when the software itself is the business advantage. If a ready-made product covers most of the processes without development, that is usually the faster route, and we will tell you so in the first consultation.

Is custom software more expensive in the long run?

Not necessarily, but it is not automatically cheaper either. The subscription for off-the-shelf software grows with the number of users and plans, while with a custom system operation and further development are an ongoing cost. Which costs less depends on the planned period of use, headcount, integrations and how often things change; it is worth calculating for the specific case.

What happens to our data if we cancel the SaaS?

That depends primarily on the contract, so check it when choosing. Under the EU Data Act, the contract must specify exhaustively which data can be ported and provide at least 30 calendar days to retrieve it; and under the GDPR, personal data must be deleted or returned at the end of the service, at the choice of the controller. In practice, a trial export shows how usable the data is in another system.

Can the two be combined?

Yes, and for many companies that is the workable route: the off-the-shelf system stays for standard tasks, a custom integration connects it to the other systems, and a custom module is built for whatever makes the company different. The precondition is that the off-the-shelf system is accessible through a documented API.

Who will own the source code?

With off-the-shelf software and SaaS, the source code belongs to the vendor and the company receives a right of use. With custom development, the contract governs source code and usage rights, with us too.

How we can help

Mesterséges Intelligencia Központ Kft. develops custom software and connects off-the-shelf systems, using artificial intelligence too where it saves real work: we connect language models from OpenAI (ChatGPT), Anthropic (Claude) and Google (Gemini) to existing systems. The first consultation is free, and we will also tell you if an off-the-shelf product is enough. If custom development is needed, we measure its functional size in COSMIC function points and derive the offer and the schedule from it. We sign a non-disclosure agreement (NDA) on request, and after handover we also provide operation and maintenance. The contract governs source code and usage rights.

Details are on the Custom software development page. If you would like to talk to us about your own situation, write to us using the details on the Contact page.