Build or buy a Shopify integration

A capable developer can connect Shopify to an accounting system. The API is well documented, the data is available, and a first working version is a matter of weeks rather than months.

That is why build-or-buy is decided on the wrong basis so often. The build is the visible, estimable part. The obligation that follows it is neither.

What building actually commits you to

Seven things, and only the first is a project.

The initial build. Authentication, reading orders, mapping to your chart of accounts, handling the historical import.

Quarterly API upgrades. Shopify ships four versions a year and retires older ones on a published schedule. Somebody reviews release notes, tests, and migrates, indefinitely — see Shopify API versioning and what breaks.

The gateway side. Shopify holds no fee or settlement data for a Malaysian store, so a second integration against your payment provider is required, in whatever format it offers — see what APIs you need for Shopify reconciliation.

The courier side, if delivery cost is to reach order level, which means another integration per carrier plus invoice processing — see what a courier API actually gives you.

The completeness mechanism. Webhooks miss events, so a reconciling pull and a comparison is required, or the books will be quietly incomplete — see Shopify webhooks and why they are not enough.

The exception handling. Matching tiers, ambiguity rules, an exception queue somebody works — see the exception queue and how to size it.

Everything a provider changes. A gateway alters a file format, a courier changes a status vocabulary, a carrier is replaced. Each one is unscheduled work landing on whoever owns the code.

The first item is a project with an end. The other six are a standing commitment, and they are what the decision is actually about.

The key-person problem

The specific risk of an in-house build in a small business, and it is worth naming plainly.

The integration is usually written by one person. It works. It is understood by them, documented lightly, and it runs without attention for long enough that nobody thinks about it.

Then that person leaves. The code still runs, until an API version retires or a provider changes a format, and at that point nobody knows how it works, why a particular decision was made, or what the untested edge cases are — see when the only person who understood it resigns.

The failure is not the departure. It is that a finance-critical system had one point of knowledge and nobody noticed while it was working.

When building is genuinely right

Not never, and the conditions are specific.

Your requirement is genuinely unusual. A business model, product structure or channel arrangement that no available product handles. This is rarer than most businesses believe, and worth testing against actual products before concluding.

You have real engineering capacity, more than one person, with an existing obligation to maintain systems.

The integration is a competitive advantage rather than plumbing. If how you connect your store to your accounts is part of why customers choose you, own it.

You are large enough that the cost comparison inverts. At sufficient scale, licence costs exceed the fully loaded cost of maintaining your own.

If two or more of those apply, building is defensible. If none do, it is usually a decision to spend engineering capacity on something that is not your business.

When buying is right, and what to check

For most Malaysian retailers and ecommerce businesses, buying is the straightforward answer — with the qualification that not every product covers the same ground.

The specific thing to verify is coverage across all the sources, not just Shopify. A product that reads Shopify beautifully and does nothing with your gateway's settlement data has solved a third of the problem, and the third it has solved is the easy one — see the three-way match a Malaysian store needs.

The questions to put to a vendor are specific enough to deserve their own treatment — see what to ask a Shopify integration vendor.

The middle position

Frequently the right answer and rarely considered.

Buy the core and build the edges. A maintained product for the standard integration — Shopify, gateways, banks, couriers — plus your own work for whatever is genuinely specific to you, built on top rather than instead.

That keeps the recurring maintenance burden with a vendor, where it belongs, while leaving you able to handle the requirement that made you consider building in the first place. It needs a product with a usable interface for extension, which is worth asking about explicitly.

The question to ask yourself before starting any build: who maintains this in three years, and what happens if they are not here? If there is no good answer, the build is not finished when it works.

Common questions

Is building a Shopify integration difficult?

The initial build is not — a capable developer can connect Shopify to an accounting system in weeks. What follows is the commitment: quarterly API version upgrades, a separate gateway integration because Shopify holds no settlement data for a Malaysian store, courier integrations and invoice processing, a completeness mechanism, exception handling, and unscheduled work whenever any provider changes something.

What is the main risk of an in-house integration?

That it was written by one person who understood it, worked without attention for long enough to be forgotten, and then left. The code keeps running until an API version retires or a provider changes a format, at which point nobody knows how it works or why particular decisions were made.

When does building make sense?

When your requirement is genuinely unhandled by available products, when you have real engineering capacity beyond one person with an existing maintenance obligation, when the integration is a competitive advantage rather than plumbing, or when you are large enough that licence costs exceed the fully loaded cost of maintaining your own. Two or more of those makes it defensible.

Is there a middle option?

Yes, and it is often the right one: buy the core integration across Shopify, gateways, banks and couriers, and build only what is genuinely specific to your business on top of it. That leaves recurring maintenance with a vendor while keeping you able to handle the unusual requirement, provided the product offers a usable way to extend it.

Related: what it takes to build a Shopify connector · what to ask a Shopify integration vendor · why integration depth beats feature count