Off-the-Shelf or Custom ERP? A Practical Decision Guide

Sooner or later, every growing business has to choose between off-the-shelf and custom ERP. On one side are established packages such as Logo, Mikro, Netsis and SAP, maintained by their vendors and partners and updated as regulations change. On the other is custom ERP software built around the way your company actually works. It is the ERP version of the build vs buy question, and in practice the answer is rarely one or the other; it is about putting each in the right place. This guide covers when a packaged ERP is enough, where it starts to strain, the hybrid model that combines both, total cost of ownership, implementation risks, a decision checklist and how to scope a custom ERP in phases.

The difference between off-the-shelf and custom ERP

A packaged ERP, also called an off-the-shelf ERP, is built by a software vendor for many businesses, sold as a licence or subscription and usually implemented by one of the vendor's partners. In Turkey, Logo, Mikro and Netsis are especially common among small and mid-sized companies, while SAP covers different scales with products such as Business One for smaller firms and S/4HANA for large enterprises. These packages ship ready-made accounting, finance, stock, purchasing and sales processes, and changes in tax and e-invoicing rules are handled through updates from the vendor or its partners.

Custom ERP software is designed and built around your own processes. Screens, approval flows, reports and the data model follow how the company really operates rather than how a generic template assumes it does. You set the roadmap, and with the right contract you also own the source code. In return, maintenance, security and further development become a shared responsibility between you and your development team.

When a packaged ERP is the right call

If your processes are close to what the package assumes, an off-the-shelf ERP is usually the fastest and least risky start. It tends to make sense when:

• Your processes are standard. If purchasing, sales, stock, customer accounts and accounting look much like other firms in your sector, the built-in flows will do the job.
• Statutory accounting is the priority. The e-ledger, e-invoicing, tax return preparation and changing tax rules are exactly what package vendors keep up with. Carrying that load in your own software is a serious commitment.
• You need to start quickly. A package goes live after installation, configuration and user training; you do not wait for core functions to be built from scratch.
• No one is ready to own the software. With a package, maintenance and updates sit largely with the vendor and its implementation partner. Custom software needs someone inside the company to prioritise requests and a development team to look after it.
• The ecosystem matters. Accountants, finance staff and new hires often already know these products.

Where packaged ERPs start to strain

The clearest sign you have hit the limits of a package is a team keeping spreadsheets, paper forms or chat groups alongside the ERP. It usually shows up in the following areas.

Non-standard production

Make-to-order work, bills of materials that change with every order, subcontracted steps, recipes that vary by batch or on-site assembly do not always fit a package's production module. Work orders get opened in the system while the real tracking happens somewhere else, so cost and lead-time figures stop being reliable.

Field operations

Sales reps, service technicians, installation crews and staff counting stock on site do not work at a desk, and ERP screens designed for the office do not suit them. A package's mobile options may not match how your field team works, and needs such as offline use, route and visit planning, photos, location or customer signatures often call for a separate app. For field sales, this is the gap we built our own product for: BernSFA, a mobile sales app that works with Logo, Mikro, Netsis and SAP.

Multi-channel sales

When the same stock is sold through a dealer portal, an online store, marketplaces such as Trendyol and Hepsiburada and a field team at once, orders need to land in one place, stock has to be reserved correctly across channels and returns need tracking. Packages usually reach these channels through plug-ins or third-party connectors, and as channels multiply, people end up fixing mismatches between them by hand. At that point a separate order layer that also handles marketplace integration is usually the cleaner design.

Customisations that keep piling up

Bending a package to fit your business has its own cost. Custom screens, fields and triggers added to a package have to be retested, and sometimes rewritten, with every version upgrade. The more you customise, the less you get from the package's biggest strength, regular low-effort updates, and over time upgrades start getting postponed.

The hybrid model: accounting in the package, operations in custom software

The setup we recommend most often treats the two approaches as complementary layers rather than rivals:

• Statutory accounting stays in the package. The general ledger, e-ledger, tax return preparation and regulatory updates run in Logo, Mikro, Netsis or SAP. E-invoices, e-archive invoices and e-dispatch notes are still issued through the package's e-document module or your GİB-authorised private integrator (özel entegratör), and your accountant keeps working in a familiar system.
• Operations run in custom software. The work that sets your company apart, such as production tracking, warehouse and dispatch, field teams, service or multi-channel order management, runs in web and mobile apps designed for those processes.
• The two systems talk both ways. In a typical setup, customer accounts, product codes, prices and balances flow from the package to the operations software; orders, shipments, stock movements and billable transactions flow back.

The model stands or falls on the integration. Decide up front which system owns each piece of data, write records into the package through the ERP's own services, and make sure failed transfers are flagged rather than silently lost. We compare the ways to connect to Logo, Mikro and Netsis in our article on ERP integration methods. SAP Business One is usually integrated through the Service Layer or the DI API, and S/4HANA and ECC through OData services, BAPI/RFC or IDocs; our SAP integration page covers the options. For connections specific to your setup, see our ERP integration page.

The hybrid model also splits the risk. Because the accounting package stays in place, the custom side can grow module by module, and even if one module needs rework, your statutory books carry on in the package as before. The package stays lean as well, so upgrades remain simpler.

Off-the-shelf vs custom ERP vs hybrid, side by side

ERP total cost of ownership: what to count

A common mistake in choosing an ERP is comparing first-year quotes only. A fair comparison looks at everything the system costs over several years of use. Rather than quoting figures, here are the items to include:

• Packaged ERP: per-user or per-module licences or subscriptions, implementation and consulting, training, update and support fees, customisations and the work of adapting them at each upgrade, and licence costs that grow with headcount.
• Custom ERP: discovery and analysis, design and development, servers or cloud hosting, security updates, backups and monitoring, bug fixes and ongoing development for new needs.
• Both: data cleansing and migration, integration upkeep, the time your staff put into the project and lost productivity during the switch.
• Hidden costs: side spreadsheets, re-keyed orders and decisions made on late or incomplete data cost money too, but they never appear on an invoice, so they are usually left out.

We break down what drives the cost of custom software in our article on software project costs. After a discovery call we share a transparent quote, either as a fixed project price or a monthly retainer, and offer monthly support packages once the system is live.

Implementation risks and how to reduce them

Whichever route you choose, ERP projects tend to struggle for similar reasons:

1. Vague scope. "Let's put everything in one system" turns into a project that never ends unless it is prioritised. Define scope module by module.
2. Messy master data. The same product under several codes, duplicate customer records and inconsistent units cause trouble in any ERP. Cleaning data should be one of the first tasks.
3. Users left out of design. If warehouse, production and field staff are not involved, the system will be right on paper and awkward in practice.
4. Integration left until last. Which records go to the package, as which document types and with which codes, should be designed together with the first module. Test against a test company or a copy of the database, never the live accounting company.
5. Big-bang cutover. Moving every department on the same day means one problem can stop the whole company. Starting with a pilot team, line or warehouse limits the damage.
6. Key-person dependency. In custom software, undocumented code and knowledge held by a single developer are a serious risk. Source code ownership, documentation and maintenance terms belong in the contract.

A checklist for choosing an ERP system

We have turned the main ERP selection criteria into questions. Your answers will point you in the right direction:

• Does the team regularly keep spreadsheets, paper or chat groups next to the ERP? For which processes?
• Which process sets us apart from competitors: production, warehouse, field, service or sales channels?
• Can that process run on the package's standard flow, or would it need constant customisation?
• Does the field team need to use the system on mobile, and offline when there is no signal?
• How many sales channels share the same stock, and where do their orders come together?
• Which system will carry statutory accounting and compliance?
• Is there someone in the company who will own the system and prioritise requests?
• Have we compared costs over several years, including licences, customisation and development?

If most answers point to standard processes, stay with a packaged ERP. If one or two differentiating processes stand out, the hybrid model is usually the most balanced path. If most of your operations do not fit a package, a broader custom ERP makes sense, with statutory accounting still kept in a package.

How to scope a custom ERP in phases

Building a custom ERP in phases, rather than all modules at once, keeps both risk and budget under control. Our approach looks roughly like this:

1. Discovery. We walk through processes with the teams involved, collect the spreadsheets they keep outside the package and map data sources and integration points. The output is a prioritised module list and a clear timeline.
2. First module. We start with the process that hurts most, such as production tracking or warehouse management, and build it together with its integration to your accounting package.
3. Pilot and rollout. The module goes live with one team, line or warehouse first, is refined from feedback and then rolled out company-wide.
4. Connected modules. Processes linked to the first module, such as purchasing, dispatch, service or field work, are added one at a time, each usable on its own.
5. Reporting and automation. Once the data has settled, management dashboards, alerts and automated workflows follow.

When you write down the scope of each phase, make sure it answers these questions:

• Roles and screens: who will use the module, on which devices and with which permissions?
• Data ownership: is each type of data created in the operations software or does it come from the package?
• Integration points: which records go to the package, when and as which document type, and if a transfer fails, who sees it and where?
• Acceptance criteria: which scenarios must work end to end before the module counts as ready to go live?
• Out of scope: what will this phase deliberately not do? Writing it down stops the scope from quietly growing.

Each phase sharpens the scope of the next, and what you learn from the first module makes the later ones better. To start pulling your requirements together, try our project planner.

Bottom line

There is no single right answer for every business. For standard processes, a packaged ERP is a fast and safe start; for the processes that set you apart, custom software replaces the workarounds your team has built around the package. For most companies the most balanced result is to keep statutory accounting in a package, run operations on custom software and connect the two with solid integration.

At BernSoftware we do not try to replace your accounting package; we build the operations software around it and integrate the two in both directions. See our custom ERP development page for a full system, our custom software development page for business apps beyond ERP, or get in touch to talk it through.