Off-the-Shelf or Custom Business Software: Total Cost and the Exit Test

The "off-the-shelf or custom" question usually reaches you as a comparison between two numbers: a monthly subscription per user, against a one-time build quote. Both numbers are real, and neither is enough to decide on. What actually determines which option costs less and risks less in your situation is four things you can check before you sign: what the bill looks like in year three rather than month one, what you can take with you the day you leave, which parts of your requirement are configuration and which need code, and whether a regulatory obligation settles the matter before any arithmetic.

This guide is written for a business owner or operations manager in Egypt, Saudi Arabia or the Gulf holding two quotes for a management system: inventory, sales and accounts; customer relationships; or an internal system for a workflow of your own. There is no universal answer here. In plenty of cases the ready-made system is the right call, and you will see below exactly when. If you have not yet settled which kind of system you need, start with the difference between ERP and CRM.

One scoping note first: if your decision is specifically about an online store, a rented platform versus a store built for you, that has its own arithmetic in custom store or ready-made platform. And if you are already on a ready-made system and have decided to move, the implementation sequence is in migrating your store to a custom system.

First: you are comparing two bills with different shapes

The ready-made bill is flat in its first month and climbs with headcount and usage. The custom bill is high at the start and then settles into hosting and maintenance. The only fair comparison stretches both across the period you actually intend to run the system, and three to five years is realistic.

Before you fill in the table, read the vendor's own pricing page instead of asking the sales rep. Published pages say important things in small type. The Dynamics 365 Business Central pricing page (accessed September 2026) lists three tiers: Essentials at $80 per user per month paid yearly, Premium at $110, and Team Members at $8 for people who only need to read data, approve workflows and create or update selected information. The same page adds at the bottom that the prices shown are for informational purposes and may not reflect actual list price because of currency, country and regional variants, and that the AI agents inside the product require Copilot Credits sold separately plus an Azure subscription.

Three things come out of one page and change your arithmetic: not every employee needs a full seat, a price written in dollars is not necessarily what you will pay in your currency, and a feature demonstrated to you may be a separate line on the invoice. The same logic repeats elsewhere. The Zoho CRM pricing page explains that "team users" are a separate licence purchased from the add-ons page in the Zoho Store, that those users cannot own records or reach reports and dashboards, and that limits such as monthly tracked website visitors can be extended at additional cost once exceeded. So compare your expected usage against each plan's limits, rather than the plans against each other.

And an advertised discount is not a permanent price. The Odoo pricing page notes in its footnote that the discount runs for twelve months and applies to the users ordered initially, which means the employee you add in year two may be priced differently from their colleagues. Ask the vendor one specific question: what is the renewal price in years two and three for the expected number of users, in writing?

The lines you fill in for each option:

Detailed figures for these lines in the Egyptian market, including published licence prices and implementation packs, are in our ERP cost guide, so there is no reason to repeat them here. What you need at this stage is one thing: two numbers over the same period, not a monthly price against a project price.

Second: the exit test

This is the test that separates the two options more sharply than any feature table, and it is rarely raised in the demo. The question is simple: if you decide to move after two years, what comes out with you, in what format, and how long do you have?

Time is the first thing to establish, because it is finite and written down. Microsoft's data retention, deletion and destruction document (last updated September 2025) explains that when a paid subscription ends or is terminated, customer data is kept in a limited-function account for 90 days so the subscriber can extract it, after which the account is disabled and the data deleted, and no more than 180 days after expiry or termination all customer data is deleted from the account.

The picture is tighter in heavier business systems. Microsoft's document on expired subscriptions and data deletion describes a ladder measured in business days for Dynamics 365 Finance and Operations projects with insufficient paid licences: notifications to tenant admins, sandbox environments disabled four business days later, the production environment disabled three business days after that, sandboxes deleted three business days later, then the project and production environment deleted two business days after that. The document describes the deletions in those last two stages as non-recoverable, and adds that showing proof of intent to renew through a support ticket stops the process and re-enables the environments. Read that as commendable transparency from the vendor rather than a trap. The damage happens when nobody in your company knows the ladder exists.

Then comes format, which is more dangerous than time because nobody notices it until late. "Export is available" is true at almost every vendor; the question is what exactly. HubSpot's page on exporting your content and data (last updated August 2026) states that there is no way to merge all the data between HubSpot accounts, and that the route is export, then import, then recreate certain items. The export records page adds that an export carries up to one thousand associated record values per association column by default, that the "all associated records" option is available for CSV files only, and that XLS files stop at 256 columns and XLSX at 16,384, with anything beyond that dropped.

Take the practical meaning rather than the product name: customers and invoices usually come out in a comfortable table, while what links them together, the attachments, the change history and the workflows with their history are what leaks away. The outcome can be much better elsewhere. The Odoo Online documentation explains that you can download a ZIP file containing a database backup from the database manager, with the caveat that the button is disabled if the database is too large to download that way and you should contact support. The gap between exporting tables and holding a copy of the database is a large one on moving day.

Four questions to ask before signing, with the answers in the contract rather than in an email:

• Which entities are exported, and does that include attachments, history, associated records and the audit trail?
• In what format, and who bears the cost of extraction if it requires special work?
• How many days do I have after the last payment before data is deleted, and when does the clock start?
• Do I get a copy of the database, or only an export from the screens?

The same question applies to a custom system, with no exemption. The difference is that the answer comes from your own contract: ownership of the code and a repository in your company's name, database documentation, server credentials, and backups you can reach yourself. At Snaabble, for example, ownership of the source code, designs and documentation transfers to the client after delivery by a clause in the contract, and that is exactly the kind of clause you should look for in writing with any firm you engage, rather than assume.

Third: configuration or code? The difference shows up on upgrade day

When a vendor tells you the system is customisable, they are describing two very different levels of cost and risk. The first is configuration: fields, screens, rules and workflows built with the platform's own tools. The second is code written on top of the standard product. The first level travels with upgrades. The second is what breaks at them.

The vendors draw this line clearly in their own documentation. Odoo's documentation defines a custom module as any module that extends Odoo's standard code and was not built with the Studio app. The upgrade page then details what the service-level agreement covers and what it does not: upgrades of all standard applications are covered, Studio customisations are covered as long as Studio is still installed and the subscription is active, and developments covered by a maintenance-of-customisations subscription are covered. Additional modules created in-house or by third parties, including Odoo partners, are not covered without such a contract. The page states plainly that if a change in a new version breaks a customisation, it is the responsibility of the module's maintainer to make it compatible, and that a database containing custom modules cannot be upgraded until a version of those modules exists for the target release.

Business Central is equally direct. The update lifecycle for tenant customisations states that you own the extension, that you own the process of updating it and providing upgrade code if the schema changes between versions of the base application, and that an automated service validates all tenant customisations before an update is scheduled and emails the details to administrators, with a pointed caveat: if no notification address is registered, you will not be notified.

And the calendar is not yours. The update cycles document explains that there are two major updates a year, in April and October, that the update period runs five calendar months during which an update can be rescheduled, followed by a one-month grace period in which postponement options narrow, and then an enforced period in which extensions blocking the update may be uninstalled automatically so that it succeeds, with the data belonging to those extensions retained and recoverable once a compatible version is installed.

The practical conclusion is straightforward. Open your requirements list and mark each line "configuration" or "code". The sum of the "code" lines on top of a ready-made system is a recurring obligation on you, on a schedule the vendor sets. One or two lines is fine. Half the list means you are paying for a ready-made system while carrying the burden of a custom one, and that is the worst place to stand.

Fourth: sometimes compliance settles it before the arithmetic

If your business is subject to e-invoicing or to a specific location for storing data, the question comes before cost: does this option support the obligation today, in a version available to you in your country, and who signs off on that?

In Egypt, connecting to the e-invoice and e-receipt systems is a well-defined technical requirement, detailed in our guide to connecting your system to Egyptian e-invoicing. In Saudi Arabia, phase two forces changes inside the system itself rather than around it, explained in phase two of e-invoicing. If selling happens at a till, the requirements reach the point of sale as covered in our POS integration guide, and if you run a warehouse, numbering and tracking decisions are settled before you choose a system, as in our item numbering and barcode guide.

Where data is stored is a subject of its own, covered in protecting customer data in Egypt and Saudi Arabia and in how to choose a hosting provider. What matters here is that this requirement does not automatically mean a custom system. Some vendors address it and publish the fact: Zoho's page on business software hosted in Saudi Arabia states that applications and data stay within the Kingdom, that Zoho is a CST-registered, Class-B certified cloud service provider authorised to host public and restricted data for government entities and private-sector organisations, and that it is aligned with the National Cybersecurity Authority's Essential Cybersecurity Controls and Cloud Cybersecurity Controls. That is a published vendor claim, and your job is to have it confirmed for your case: is the edition available to me the one hosted inside the Kingdom, does it cover every module I will use, and which legal entity am I contracting with?

Conversely, if your obligation touches something the product does not support in your local edition, customisation on top of the ready-made system will usually not fix it, because the issue sits in the infrastructure rather than in the screens.

Fifth: the hybrid, and when it is the right answer

Mixing the two is a sensible arrangement for many companies: a ready-made system for the standard parts that do not differentiate you, such as accounting, payroll and invoicing, and a custom system for the operation that creates your edge, such as a distribution cycle with field reps and cash collection, complex resource scheduling, or pricing with rules of your own.

This arrangement has one condition: the boundary between the two systems must be defined and written down. One source of truth per entity (who owns the customer? who owns the item? who owns the balance?), a clear direction of data flow, and an open API on both sides. This is exactly where plans from a single vendor diverge: the Odoo pricing page lists the external API under the Custom plan and not the Standard one, so make sure the plan you are costing is the one that allows the integration the whole arrangement rests on.

And cost the arrangement in full: two systems mean two upgrade calendars, a periodic reconciliation routine, and one accountable party for the link between them when it stops. If you are not ready for those three, one less-than-perfect system beats two that do not talk.

Decision signals

The list below decides nothing for you, but it summarises what recurs in "off-the-shelf or custom" cases:

Before you sign

Ask for four things in writing, whichever option you choose: the renewal price for the next two years at the expected user count; what is exported, how, and the window after the relationship ends; the support boundary between configuration and code, and who carries compatibility of customisations at upgrade time; and your requirements list split into "covered as standard" and "needs additional work", signed by the vendor. A serious vendor answers all four, and declining to answer is an answer in itself.

And if you are evaluating a system for a workflow specific to your company and have found no ready-made product that covers it without distorting how you work, write the process down as it runs today and send it to the Snaabble team. The reply arrives within 24 hours: a first reading of the scope, a time frame, and an indicative cost figure, with nothing to pay and nothing to commit to.

Frequently asked questions

Can we start on a ready-made system and move to a custom one later?

Yes, and it is a common path. What determines how hard it will be is not the decision on moving day but the exit clause you signed on the way in: whether you get your data in full with attachments and associated records, in what format, and within how many days. The implementation sequence itself is covered in our migration guide.

What should I have in the contract to guarantee I can extract my data?

Four items: the list of entities exported and whether it includes attachments, audit trail and associated records; the format; the window after the relationship ends and when it starts counting; and who bears the cost of extraction if it needs special work. Better than wording alone, run a full export during the trial and open the file yourself.

Does customising a ready-made system void the upgrade guarantee?

It depends on the level of customisation and on what your contract says. Odoo's documentation, for instance, distinguishes what is built with the platform's tools from what is written as code on top of it, and excludes modules created in-house or by third parties from upgrade coverage unless a maintenance-of-customisations subscription covers them. Ask for that classification in writing, line by line.

Our revenue is in pounds or riyals and the subscription is in dollars. Does that favour a custom system?

Not on its own. A custom system also carries dollar-priced lines such as hosting and some tooling. The difference is that its recurring portion is usually smaller and less tied to headcount. Cost both over the same period before you let currency decide.

Sources

• Dynamics 365 Business Central pricing: Microsoft, accessed 22 September 2026.

• Data retention, deletion, and destruction in Microsoft 365: Microsoft, last updated 29 September 2025.

• Expired subscriptions and data deletion: Microsoft.

• Update Lifecycle for Customizations of Business Central Online: Microsoft, last updated 29 August 2024, and Update cycles.

• Odoo documentation: pricing, Upgrade, Upgrade a customized database, Odoo Online.

• Export your content and data (last updated 25 August 2026) and Export your records: HubSpot.

• Zoho CRM pricing and Business software hosted in Saudi Arabia: Zoho.

All live pages above were accessed on 22 September 2026, and the prices and windows they state can be changed by their owners.