Custom ERP Integration vs Ready-Made App: Which Should You Choose?

The choice between a ready-made ERP app and a custom integration is usually framed as a price comparison: a monthly subscription against a development quote. The figure that tends to decide it is a different one: how many orders, prices and stock movements fall outside what the connector understands. A ready-made ERP app is often the better choice when those exceptions are rare and the team can adjust minor processes to fit it. A custom ERP integration becomes worth its higher build and upkeep cost when contract pricing, kits, multi-warehouse routing or approval steps are part of daily trade, because otherwise each exception turns into manual work that grows with order volume.

Seen this way, the ERP connector vs custom integration question is less about technology than about where the business’s rules will live: inside a vendor’s product, inside code the company owns, or in staff routines that patch the gap. Shopify, WooCommerce and Adobe Commerce stores all face the same choice, although the connectors on offer differ by platform and ERP. Whichever route is chosen, ecommerce ERP integration is far easier to scope once the exceptions are written down rather than remembered.

What a Ready-Made App and a Custom Integration Each Include

A ready-made connector is a product built once for many merchants: a Shopify App Store app, a connector supplied by the ERP vendor, or an integration-platform (iPaaS) template. The vendor defines its data model, sync schedule and error screens, and the merchant configures within them. Configuration can reach further than expected: Oracle’s NetSuite Connector documentation describes custom order mappings built from conditional “Check If” and “If True, Set Value To” rules, labelled an advanced feature.

A custom integration is software the business commissions and owns. It usually runs as middleware outside the storefront, uses the Shopify GraphQL Admin API or the WooCommerce and Adobe Commerce REST APIs, and reaches the ERP through whatever interface it offers, from REST to SOAP or file exchange. The logic can match the business exactly, and so can the responsibility: someone has to monitor, fix and update it.

The Middle Ground: Extending a Connector

Between the two sits an option that is easy to overlook: extending a vendor connector. In Microsoft’s developer documentation on extending the Business Central Shopify Connector, a per-tenant extension can subscribe to the connector’s events and adjust flows such as order creation or stock calculation, but it cannot modify the API calls the connector makes. A hybrid approach adds code that calls Shopify directly, which is more flexible but requires registering an unlisted Shopify app and writing the communication logic.

That route suits companies with mostly standard needs and one or two awkward rules, such as assigning point-of-sale orders to a dedicated customer account. It carries its own dependency: Microsoft notes that redesigns needed to keep pace with Shopify have at times caused breaking changes for such extensions.

When a Ready-Made ERP App Is Enough

A ready-made ERP app is usually the stronger option when the business sells mostly to consumers at list prices, ships from one or a few locations, and runs an ERP with a well-maintained connector for its platform. The connector’s idea of a product, an order and a stock level is then close to the company’s own, and the remaining differences can often be absorbed by adjusting a process. The advantages of a ready-made ERP app go beyond the lower starting cost:

• Faster relief from manual work. Setup is configuration and testing rather than design and development, so re-keying orders into the ERP can stop sooner.
• Shared maintenance. The vendor tracks platform API changes for all its customers at once. Microsoft, for instance, adopts a newer Shopify API version in major Business Central releases, so merchants receive it by upgrading.
• Tested behaviour. A connector used by many stores has met refunds, partial fulfilments and cancellations many times, so common edge cases are more likely to be handled than in a first-version build.

The limits appear at the edges of the vendor’s model. A connector may sync orders and stock reliably yet have no place for contract prices, customer-specific catalogues, pack sizes that differ between the ERP and the store, or orders that need approval before they reach the warehouse. Subscription pricing may also rise with order volume or store count. None of this rules a connector out, but each point should be tested before signing rather than discovered after go-live.

When a Custom ERP Integration Is Worth the Investment

A custom ERP integration tends to justify itself when the rules that make the business profitable are the same rules the connector cannot express. Typical examples include B2B and hybrid stores with negotiated price lists and credit terms, manufacturers selling kits assembled from ERP components, groups invoicing through several legal entities, and companies running a legacy or regional ERP for which no maintained connector exists.

In those cases the alternative to custom code is rarely no code at all. It is usually a person, a spreadsheet or a nightly CSV import compensating for what the connector leaves out, a cost that sits in salaries rather than the software budget and grows with every order, customer group or warehouse.

The pattern is visible in WD Market’s A.M. Ozoli B2B pricing and sales automation project. Pricing knowledge sat with a few employees and their spreadsheets. Once the pricing rules were built into one central system, the case study reports quoting time “reduced from ~2 hours to under 30 seconds”. The project was a CRM and pricing system rather than a store connector, but it shows what changes when business rules move from people into software the company controls.

A custom ERP integration also brings costs a connector does not. The business owns uptime, error handling and documentation, and needs a developer or partner who understands both systems. Delivered and then left unattended, it may age faster than a maintained app, so ownership belongs in the decision from the first conversation.

ERP Connector vs Custom Integration: Six Tests for Your Workflows

Settling the ERP connector vs custom integration choice needs evidence about the specific business. Each test below can be answered with a sample of real orders and a conversation with operations and finance, before any vendor demo.

1. What Share of Orders Needs a Manual Touch Today?

Pull a recent month of orders and count how many required someone to intervene: editing a price, splitting a shipment, re-keying a customer or holding an order for approval. A small, stable handful suggests a connector plus a written procedure may be the cheaper system overall. Frequent or rising interventions reveal rules the integration will have to carry, whichever route is chosen.

2. Does the Connector’s Data Model Match Yours?

Compare how the ERP and the store describe the same things: units of measure, variants, bundles, price lists, tax codes, customer accounts and locations. Some mismatches can be bridged by configuration, as with the NetSuite Connector’s mapping rules, or by extensions where the vendor allows them. Where a concept does not exist on one side at all, for example customer-specific prices on a connector that syncs a single price per variant, custom logic is usually required.

3. Which System Owns Each Field, and Which Way Does It Flow?

List the fields that move between systems and give each an owner and a direction. Ready-made apps typically ship with fixed directions, such as orders from store to ERP and stock from ERP to store. That works until a field must originate in different places for different channels, or 3PL fulfilment updates must reach both systems. The longer the list of exceptions, the stronger the case for flows the company defines itself.

4. How Much Volume, and How Fast Must It Move?

Volume and timing affect both options. The Shopify Admin API is rate-limited, so anything that handles peak sales events needs queuing and batching rather than one call per change. A fixed sync schedule may suit a few hundred products and lag behind tens of thousands of variants with several price updates a day, so ask vendors how their product behaves at peak, not on average.

5. Will You See Failures Before Customers Do?

Integrations rarely fail loudly. WooCommerce’s documentation states that it automatically disables a webhook after more than five consecutive delivery failures, so an unmonitored endpoint can quietly stop receiving order events. On Shopify, the standard order scopes cover orders created within the last 60 days unless an app is granted the read_all_orders scope, which matters when a reconciliation job needs to look further back. Whatever the route, establish what logs, retries, alerts and reconciliation reports exist, and who receives them.

6. Who Will Keep the Integration Current?

According to Shopify’s API versioning documentation, a new API version is released every quarter and each stable version is supported for a minimum of 12 months, so anything calling the Admin API needs periodic updates. Microsoft’s FAQ for its connector describes Shopify deprecating fields between versions and states that an integration which falls behind stops working. A connector vendor absorbs that work for every customer; a custom ERP integration needs a named owner, a budget line and a test environment for it.

Comparing the Three Routes Side by Side

Read across, the table describes a sequence rather than a winner. For many stores the sensible order is to test the simplest route that covers their rules, extend it where the vendor permits, and commission custom code for the remaining gaps or when no maintained connector exists. Going straight to a custom ERP integration makes sense when the core flows, not just the edges, fall outside the connector’s model.

Key takeaway: decide by where your exceptions should live. If they are occasional, a ready-made ERP app plus a written procedure is often enough. If they are how the business trades, they belong in an integration the company controls and maintains.

Comparing Costs Over Several Years Rather Than at Launch

Launch cost usually favours the connector, so on its own it reveals little. A fairer comparison runs over three years with four lines per option: licence or build, implementation and testing, maintenance, and staff time spent on workarounds. The last line often changes the answer, and the manual-touch count from the first test is the way to estimate it.

For a ready-made ERP app, check whether pricing rises with orders, stores or ERP users, and what a second storefront or legal entity would cost. For a custom build, budget for hosting, monitoring and the API upgrades the platform requires each year. As one reference point, WD Market publishes its own integration pricing: fixed-scope projects start at €3,000 and run to €15,000 and above, while monitoring retainers range from €200 to over €1,000 per month. Other providers price differently, and complex multi-entity work is normally scoped individually.

A Decision Process That Avoids Building the Wrong Thing

1. Document workflows and exceptions. Write down how an order moves from checkout to invoice, including returns, partial shipments and B2B approvals.
2. Build a field ownership list. For products, prices, stock, customers, orders, fulfilments and refunds, record the system of record and the direction of flow. Both options are tested against this list.
3. Shortlist connectors and test them with real data. Run two or three candidates against a development store or sandbox using awkward real orders rather than the vendor’s demo data, and note every requirement each one fails.
4. Classify every gap. Decide whether each failure can be solved by configuration, by an extension the vendor supports, by a process change, or only by custom code. The proportion in the last group largely answers the question.
5. Compare total cost and ownership. Apply the multi-year comparison to the remaining routes, including who maintains each and how API changes are handled.
6. Plan monitoring before launch. Agree logs, alerts, a reconciliation report and a named owner for failures, whether the integration is bought or built.

When most gaps from step four involve trade customers, such as company accounts, negotiated price lists, payment terms or approvals, the integration decision is bound up with how the B2B storefront is built. It is then worth scoping the integration together with the store’s B2B pricing, account and ordering workflows, so that the store and the ERP are designed to agree on the same rules.

Internal expert input required: add one verified WD Market example of a connector evaluation (platform, ERP, gaps found, route chosen), approved by the client for publication.

Mistakes That Undermine Either Choice

• Choosing the tool before mapping the workflow. Selecting an app from a feature list, or commissioning a build from a short brief, tends to miss the exceptions that generate the most manual work.
• Stretching a connector beyond its design. Layering scripts, extra apps and spreadsheet steps around a connector to cover core needs can produce the cost of custom work without its ownership, and each vendor update becomes a risk.
• Treating a custom build as a one-off project. Without a maintenance budget and monitoring, a bespoke integration can fall behind platform API versions and fail at an awkward moment, often during a busy trading period.

Choosing Where Your Integration Rules Should Live

Choosing between a ready-made ERP app and a custom ERP integration turns less on launch price than on where exceptions will be handled. A connector suits standard workflows on a supported ERP and passes platform upkeep to its vendor; an extension covers a few specific rules. Custom work earns its cost when pricing, product structures, entities or approvals sit outside a connector’s model, provided someone owns it after launch. Testing candidates against real orders, assigning field ownership and comparing costs over several years usually make the answer visible before budget is committed.

From Integration Shortlist to a Connection Your Team Can Rely On

If the tests leave the answer unclear, an integration assessment can map the workflows, fields and gaps and recommend a route, including the cases where a well-configured connector is the better answer. For the scope of that work, from data flow mapping to monitoring after launch, see how WD Market approaches ecommerce ERP integration.

To talk through your own set-up, contact our engineering team with the platform, the ERP and a few orders that currently need manual handling. WD Market also publishes practical integration and operations notes on its LinkedIn company page.

Questions About ERP Apps and Custom Integrations

Can we start with a ready-made ERP app and switch to a custom integration later?

Yes. For many stores this is the more cautious path. A connector ends manual order entry quickly and shows where it falls short. The later switch is easier if field ownership and the connector’s mappings are documented from the start, because a custom build needs the same decisions. Plan the cut-over for a quiet trading period and compare outputs from both before the old connector is switched off.

Is a custom ERP integration more reliable than an app?

Not automatically. Reliability depends on error handling, retries, logging and monitoring, and a well-maintained connector used by many stores may cope with common failures better than a new build. A bespoke integration can be more dependable for unusual workflows because it is designed around them, but only if someone watches it and keeps it current with platform API versions. Ask any provider, vendor or developer, to show how failures are detected and replayed.

Who should own an ERP integration after go-live?

Ownership has two parts: a business owner who decides how data should flow and a technical owner who keeps it working. With a connector, the technical side is shared with the vendor, but someone internal still reviews errors and configuration changes. With a custom build, the technical owner is the developer or partner maintaining it, ideally under an agreement covering monitoring, fixes and platform updates. Without named owners, customers tend to notice failures first.

What should we prepare before asking for an integration quote?

Prepare a list of systems and versions, the data that moves between them and in which direction, typical and peak order volumes, and a set of real orders that currently need manual handling. Add pricing rules, warehouses and any approval steps. With that material a provider can say whether a connector, an extension or custom work fits, and price it with fewer assumptions. A team experienced in ecommerce ERP integration can then assess it and propose a route before any development begins.