ERP Selection: Off-the-Shelf Package or Custom System? 12 Questions to Ask Before Deciding

When a business says "We need to move to ERP," it actually makes two separate decisions: which processes will be digitalized and through which software model these processes will be managed. The first decision is business analysis; the second is a choice between an off-the-shelf package and a custom-built system. In this article, we focus on the second decision and place the real costs, risks, and advantages of both paths side by side.

Process first, software second

The most common mistake in ERP selection is starting software demos before processes are clarified. Demo screens are impressive; however, if your purchasing approval chain, branch structure, or foreign currency-based pricing is not on those screens, the adaptation cost remains hidden in the unseen part of the offer. Therefore, we recommend preparing these three documents during the discovery phase:

• Process map: End-to-end flows from request to invoice, onboarding to payroll, and approval authority at each step.
• Data inventory: Which data is kept where (accounting program, Excel, email), and which ones should be the "single source of truth."
• Integration list: Banks, e-invoice providers, accounting software, e-commerce channels, and SMS/email services.

Strengths and weaknesses of the off-the-shelf package

Off-the-shelf ERP packages offer a quick start for businesses with standard processes. Accounting, inventory, and basic purchasing modules are mature; legal reporting requirements are mostly updated by the vendor. The downside is that the company's unique processes have to be adapted to fit the package. The phrase "the package works this way" can eventually turn into a structure where processes are shaped according to the software.

Strengths and weaknesses of the custom system

A custom-developed system allows you to model processes as they are and ensures that the data model belongs entirely to you. Needs such as multi-company organizations, site- or branch-based authorization, and industry-specific work order flows are met more naturally here. The downside is that it requires discipline: if analysis, architecture, testing, and maintenance processes are not owned, it can turn into a project that is "constantly developed but never finishes.">

The right question is not "which one is better"; it is "which of my processes are standard and which ones differentiate us." Taking the standard from the package and the differentiator from custom development is usually the most balanced approach.

12 questions to ask before deciding

1. What percentage of our processes are industry standards, and what percentage are unique to us?
2. Do we work with multiple companies, branches, or currencies?
3. Are our approval chains role-based or person-based?
4. Who will own the data; can we get the database when the contract ends?
5. Who will update legal reporting (e-invoice, e-ledger, payroll legislation)?
6. Is integration with the existing accounting program mandatory, or will it replace it?
7. Will field teams (construction site, warehouse, service) access the system from a mobile device?
8. Is authorization enforced at the database level or only on the interface?
9. Is an audit trail (who, when, what changed) maintained?
10. Who is responsible for backup and recovery?
11. What will the license and maintenance cost be three years from now?
12. If the software development team changes, is the system documented?

Calculating the total cost of ownership accurately

In both models, the initial quote is only part of the total cost. Per-user licenses, module additions, and adaptation consultancy in packaged software; maintenance, server infrastructure, and new feature development budgets in custom systems must be taken into account. Making the comparison over the same time horizon (e.g., three or five years) prevents misleading results. The only general rule we can give here is this: whichever path you choose, do not underestimate data migration and training costs.

The hybrid approach: Combining the best of both

In practice, the scenario we encounter most frequently is the hybrid structure. For example: official accounting remains in the existing accounting program, operational processes (purchase requests, assets, timesheets, progress payments, work orders) are managed in a custom-developed system, and a planned data transfer is established between the two systems. This approach leaves the burden of legal reporting to specialized software while allowing the business to model its unique processes without restriction.

Cy Logic's approach

We start every project with discovery and analysis; when an off-the-shelf package will suffice, we state this clearly. When we develop a custom system, we treat modular architecture, row-based authorization on PostgreSQL, and audit logs as standard components. The goal is for the business to have a digital roof that does not have to be rewritten as it grows.

Three common mistakes

1. Deciding with a demo

Demo environments are prepared with clean data and ideal scenarios. Your actual data is full of missing fields, duplicate current accounts, and exceptions. Before making a decision, request a pilot study with a small sample of your own data (e.g., one month of purchase requests and one construction site's timesheet). The purpose of the pilot is not to like the software, but to see the true scale of the adaptation need.

2. Leaving integration to the end

The approach of "Let's set up the ERP first, and connect the bank and e-invoice later" leads to a dual-entry period lasting months after going live. The integration list and the technical requirements of each integration (API access, test environment, contract) must be clarified during the selection phase.

3. Leaving the user to the end

The ones who will use the ERP every day are the warehouse manager, the purchasing specialist, and the site supervisor; not management. Failure to involve these people in the selection process results in a "the system exists, but we are continuing with Excel" outcome.

An example evaluation framework

The table below is a fictional example; weights vary according to the business. The goal is to make the decision based on recorded criteria, not emotion.

CriterionQuestionPackaged packageCustom system Process fitCan our processes be modeled without changing?PartiallyYes Legal reportingWho makes legislation updates?VendorIntegrated accounting program Data ownershipCan we get the database?Contract dependentYes Start speedWhen is the first module used?FastPhased Long-term costWhat are we paying three years later?License + customizationMaintenance + development

Transition plan: In what order?

Whichever model you choose, the order of transition is the same: master data first (current and stock cards, personnel), then a single process where daily transactions are most intensive, followed by approval chains, and finally reporting. Master data cleanup is the most underestimated and time-consuming step of projects; when duplicate current accounts and inconsistent stock codes are carried over to the new system, the new system produces old problems faster.

Notes in the context of Cyprus and Turkey

In Turkey, e-invoice, e-archive, and e-ledger obligations make it almost mandatory for the accounting side to remain in software compatible with the Revenue Administration; this highlights the hybrid model. For businesses operating in the TRNC, the need to work with different currencies and consolidate with group companies in Turkey is common; the multi-company and multi-currency structure of a custom system can be decisive here. In both cases, verify legal and financial requirements with your financial advisor; software decisions are built on top of these requirements.

If you would like to evaluate your ERP decision together, you can reach out to us with a draft of your process map; that is the most beneficial document in the initial meeting.