You already know you need to connect your ERP with another system -an online store, a logistics platform, the bank-, but there's a prior decision almost nobody frames properly from the start: do you use a connector that already exists, or do you ask for a custom development? It's not a minor technical question, because getting it wrong here means either paying too much for something you didn't need, or ending up short with a solution that doesn't cover your real case.
What each option actually is, no detours
A standard connector is an integration already built and tested for a specific, frequent case -connecting Business Central with Shopify, for example- that gets configured for your company instead of programmed from scratch. A custom development is an integration designed specifically for your case, when there's no existing connector that covers what you need or when your process has particulars that a generic connector doesn't account for.
Neither one is «better» in the abstract: they're the right answer to different situations, the same way we explain when comparing EDI and API as two technologies that solve different needs, not one better than the other in every case.
When a standard connector is the sensible choice
If your case is one of the ones that repeats across hundreds of companies -connecting the ERP with a well-known e-commerce platform, with a bank for reconciliation, with an e-signature tool-, it's very likely a mature connector already exists, tested in production by other clients before you. Choosing it means starting faster, with less risk of running into unforeseen cases, and usually at a lower cost than programming from scratch something that's already solved. It's the same logic we apply in our Shopify and PrestaShop integrations: we start from a connector that's already mature and configure it -we don't rebuild it- for your specific catalogue and logistics.
When custom development is actually needed
Custom development comes into play when the system you want to connect with is specific to your sector, uncommon, or when your internal process has a particular logic a generic connector can't anticipate: specific business rules, validations unique to your operation, or a data flow that doesn't look like a standard online store's. It's also the mandatory path when a large client requires a specific EDI format from you: no generic connector helps there, because every trading partner defines its own specifications.
The question that actually decides
Before deciding, it's worth asking one very specific question: has someone already solved exactly this same problem, with the same system on the other end? If the answer is yes, a standard connector almost always wins on time and cost. If the answer is no -because the system is uncommon, because your process is different from the usual one, or because the trading partner imposes its own rules-, then custom development isn't a luxury, it's the only way the integration will actually work for your case.
A middle ground: the adapted connector
In practice, many projects aren't purely one extreme or the other. You start from a standard connector for what it already solves well -the basic sync of products, stock and orders, as in syncing stock to avoid overselling- and add specific development only for the particular cases the connector doesn't cover: a promotion unique to your store, an exclusive product with different rules, a validation from your internal process. This mixed approach is usually the most sensible on cost, because you're not paying to rebuild what already works, nor settling for a connector that falls short on what matters for your business.
Frequently asked questions
Does a standard connector fall short if my company grows or changes process?
Not necessarily, but it's a real possibility worth considering when choosing. A well-built standard connector usually includes configuration options designed to adapt to different sizes and ways of working, so many normal kinds of growth -more order volume, more product references, an additional channel of the same type- get absorbed without issue within that configuration. Where it can fall short is if the change introduces a new business logic the connector didn't account for by design; at that point, the solution isn't to scrap everything already set up, but to add specific development only for that new part, keeping the standard connector for everything that keeps working well.
Does custom development always take longer than a standard connector?
In the vast majority of cases yes, because a standard connector is already tested and only needs configuring for your specific case, while a custom development has to be designed, built and tested from scratch for your specific situation. That doesn't mean custom development is slow in absolute terms: a well-scoped project, with a clear scope from the start, can be delivered in a reasonable timeframe. What is almost always true is that, comparing both options for the same problem, if a standard connector capable of solving it existed, that connector would reach production sooner than the equivalent development built from scratch.
Can I start with a standard connector and move to custom development later?
Yes, and it's actually a common and sensible path, not a sign of having chosen wrong at the start. Many companies start with a standard connector to quickly solve the common part of the integration -syncing products, stock and orders with an online store, for example- and, later on, when a specific need comes up that the connector doesn't cover, add specific development just for that piece, without having to redo or replace what already works. Starting with the standard connector doesn't close any doors: it simply solves quickly what the market has already solved, leaving custom development for the day it's actually needed.
In summary
The question that actually decides isn't «which do I prefer», but whether someone has already solved your exact problem with the same system on the other end. If they have, the standard connector wins almost always on time and cost; if they haven't, custom development stops being a luxury and becomes the only way the integration will actually work.
If you're not sure which one fits your case, check out our EDI integration for Business Central or tell us what system you need to connect with and we'll tell you which path fits your case.