Every online store depends on one integration: the one between the storefront and the ERP. Orders, stock, prices and customers all cross it. When it works, nobody thinks about it. When it doesn’t, orders sit in a queue, stock counts go wrong, and someone starts re-typing data by hand.
Most merchants pick this integration once, at the start, and they pick it on the build price. That’s the number on the quote. It’s also the smallest number in the whole calculation.
We’ve spent ten years on every side of this. We built custom integrations for manufacturers and retailers. We ran integrations on a market-leading integration platform in production for years. And we’ve inherited scripts nobody could explain anymore. Here are the five ways we see merchants get this integration, and where the cost lands by year three.
1. The bespoke build
An agency or an in-house developer builds exactly what you asked for. You own the code. The quote looks sensible, and on paper it pays for itself against a subscription within a couple of years.
Year one is usually fine. The cost shows up in years two to five, and most of it comes from outside your business. Your ERP ships new releases on its own schedule. Your store platform retires an API version. A payment provider changes an endpoint. None of that was in the scope, so each one becomes a new ticket, a new quote, or a new project.
Then there are the changes that come from inside. When a tariff change forced one of our clients to rethink how tax was handled on a live store, the integration had to change with it, and fast. A bespoke build can do that, if the person who wrote it is still around and has the time.
By year three: you’ve paid for the build again in pieces, and the integration is only as current as the last time someone was paid to touch it.
2. The orphaned script
Nobody picks this one on purpose. It’s what a bespoke build turns into when the person who wrote it moves on.
The script keeps running, and that’s the trouble. It faithfully applies yesterday’s business rules while the business changes around it: new tax rules, new discount types, a new shipping method, a product line that doesn’t fit the old mapping. Nothing breaks loudly. The data drifts, and the team works around it.
This is the most common setup we find, and it almost always comes with spreadsheets. Custom code plus spreadsheets is the real market leader in this space.
By year three: the script is the system nobody dares touch, and a few people on your team spend part of every week covering for it.
3. The vendor on the meter
There’s a vendor, and they know your integration. But every change is an invoice, and the invoices are hard to predict.
So merchants do the sensible thing and stop asking. Small changes get handled by hand instead. The integration stays as it was at go-live while the business moves, which is path two with a support contract attached.
By year three: you’re paying for support and still working around the integration, because asking for a change feels expensive.
4. The AI-generated build
This is the newest path, and it’s spreading fast. A developer, or someone on your team, uses an AI model to write the integration. It compiles. It passes the test orders. It goes live in days.
Then it fails on the four-hundredth order, at a tax edge case nobody tested. The hard parts of an integration are the ones nobody demos: retries that don’t create duplicates, replaying a failed record safely, checking what went through against what should have, and noticing a failure at 2 a.m. None of that shows up in a happy-path test, so none of it gets built.
AI made the build cheap. It did nothing for the cost of running the thing for five years.
By year three: you have a cheap build with the same gaps as an orphaned script, and you got there sooner.
5. The catalogue platform
The big integration platforms sell ready-made connectors for well-known pairs. If you run a famous pair, like Shopify and NetSuite, and you have a team that wants a toolkit, this is a solid choice. Those pairs are well served.
Two things to watch. Pricing is usually metered, so the bill grows with your order volume even when nothing about your setup changed. And you’re licensing a tool. Someone still has to design, build and run your integration in it, usually a consultant at the start and your own team after that.
The bigger limit is the long tail. Plenty of store and ERP pairs only have a handful of companies on them worldwide. A catalogue vendor can’t justify building and maintaining a connector for five customers, so those pairs never make it into the catalogue.
By year three: a good fit if your pair is famous and you have people to run the tool. A dead end if your pair is rare.
Five questions that expose a fragile integration
You don’t need to read the code to know how your integration will age. Ask whoever owns it these five questions.
- When a sync fails at 2 a.m., who finds out, and how? If the answer is “a customer” or “accounting, at month end”, nothing is watching it.
- Can a failed order be replayed without creating a duplicate? If nobody’s sure, the first replay will tell you.
- When your tax rules, prices or shipping methods change, who updates the integration, and what does it cost? If the answer makes you hesitate to ask, you’re on path three.
- Who keeps track of the release schedules on both ends? Your store and your ERP change on their own calendars. Someone has to watch both.
- If the person who built it left tomorrow, could someone else read what it does? Field mappings, transformation rules and schedules should be written down somewhere you can get to them.
Three or more weak answers usually means the integration already costs more than its quote said.
Which path fits
- A bespoke build, if your requirements are truly one of a kind and you have engineers who’ll own the integration for years.
- A catalogue platform, if your pair is well known and you have an integration team that wants a toolkit.
- An AI-generated script, for a one-off you can throw away. Keep it off the path your revenue runs through.
- Doing it by hand, if volume is low and a mistyped order costs less than any fix.
Nobody picks paths two or three on purpose. The others drift there when nobody owns the running.
Where we sit
We built Nexbea for the gap between path one and path five: pairs too rare for a catalogue, and too important to leave to a script. We build the connector when there’s a client for it, then run it on one platform as a subscription. Monitoring, retries, API changes on both ends and changes to your own business rules are all included. The price depends on how many systems you connect, with no metering.
Inform has kept about 2,400 products, plus every order and customer record, in sync between Craft Commerce and NetSuite this way since 2024. Bocci went live on the platform this summer.
We also wrote an honest comparison of the alternatives, including the cases where we’re not the right choice. And if you want these five questions answered for your own setup, book a free discovery call.