Often the honest answer is buy, not build

Off the Shelf Connector or Custom Integration

If you ask an integration developer whether you need a custom integration, you can guess the answer. Here is ours, stated plainly: for a large number of Australian retailers and wholesalers, a packaged connector between two mainstream systems is the correct choice, and paying for a bespoke build would be a waste of money we would rather you kept.

This page is the decision framework we use before quoting anything. What connectors actually do well, the specific signs that you have genuinely outgrown one, how the costs compare over three years rather than at purchase, where a hybrid of both beats either, and the questions to ask a connector vendor before you commit.

Book an Independent Assessment (03) 9003 0111

How the Two Options Really Compare

Weeks, not months

Connector time to live

Usually measured in days to weeks where the systems are both mainstream

Three year view

Where the comparison belongs

Subscription fees accumulate, build cost is mostly up front

The 20 percent

What a connector will not do

And whether that remainder is genuinely core to your operation

Hybrid is common

Connector plus a thin custom layer

Frequently cheaper and more robust than either option alone

Four Things People Get Wrong About This Decision

The build or buy question is usually decided on the wrong evidence, at the wrong moment, by the wrong comparison.

The comparison is usually made against the wrong thing

People compare a connector subscription against the quoted price of a build, decide the connector is cheaper, and stop there. The fair comparison is total cost over three years including the subscription, per order or per record fees as volume grows, the internal time spent working around the gaps, and what it costs to leave. On the other side it is the build price plus hosting, monitoring and the ongoing changes that any integration needs as systems update. Sometimes the connector still wins comfortably. Sometimes it is closer than the sticker prices suggest, particularly where per transaction fees scale with growth.

Connectors cover the common path very well

A mature connector between two mainstream systems has been run by hundreds of businesses, which means the common cases are genuinely solid and the vendor fixes breakages caused by platform updates before you notice them. That is real value and it is undervalued by people who have only seen a connector fail at an edge case. If your requirement is orders, customers, products and stock flowing between two popular systems in a fairly standard retail pattern, a connector is very likely to do it well and for less than any build.

The question is whether your exceptions are core

Every business has requirements a connector will not meet exactly. What matters is whether those requirements are central to how you make money or are merely preferences. A wholesaler whose entire commercial model rests on customer specific contract pricing with pack size rounding has a core requirement. A retailer who would prefer order references formatted differently has a preference. The first justifies custom work, the second justifies adapting your process. Being honest with yourself about which is which is most of this decision.

Timing matters as much as fit

The right answer changes with where you are. A business doing modest online volume, about to replatform within the year, and still working out its processes should almost never commission a custom build, because the requirements will change underneath it. Start on a connector, learn what your exceptions actually are from real trading, and revisit once the platform and processes are settled. Building bespoke integration against systems or processes you are about to change is one of the more expensive mistakes in this field.

Six Tests to Apply Before You Decide

Work through these honestly. In our experience three or more clear failures point to custom work, and fewer than that points to a connector with adjustments.

A gap list

Requirement fit

List what you need the integration to do, then check each item against what the connector documents rather than what the sales page implies. Mark each as covered, partially covered or absent, and separate the absent ones into core and preference. A short gap list of preferences is a connector decision. A gap list containing things your business genuinely cannot trade without is a different conversation.

Scale reality

Data shape and volume

Connectors usually assume a fairly standard data model. Check your realities against it: number of SKUs and variants, multiple warehouses and store locations, bundles and kits, serialised or batch tracked goods, multiple entities and ABNs, several currencies, and daily order volume at peak rather than average. Also check how the connector prices at your volume, because per order fees that look trivial at current levels can become significant after a strong year.

A real number

Total cost over three years

Build both columns properly in AUD. Connector: subscription at current and projected volume, setup or onboarding fees, any per record charges, and the internal hours spent on manual workarounds for the gaps. Custom: build price, hosting and monitoring, expected change work as your systems update, and support. Include the cost of leaving each option, because that is where the difference often shows up and it is almost never in the proposal.

Risk understood

Supportability and dependency

With a connector you depend on a vendor whose priorities are theirs, including their support hours relative to Australian trading, their response when a platform update breaks something at your peak, and their commercial future. With a custom build you depend on whoever maintains it and on having proper documentation and credentials in your own possession. Neither is inherently safer. What matters is knowing which dependency you are accepting and having a plan for it.

Best of both

The hybrid option

This is the option most often overlooked and frequently the best value. Let the connector handle the high volume standard flows it does well, and add a thin custom layer for the specific things it cannot do, such as an unusual pricing rule, a transformation before records land, or a feed to a system the connector does not support. You get vendor maintained reliability on the bulk of the traffic and bespoke behaviour only where you genuinely need it, usually for a fraction of a full build.

A way out

Exit and portability

Before committing, establish what leaving looks like. For a connector: can you export the field mappings and cross reference data, what happens to in flight records, how much notice is required, and would you be rebuilding from nothing. For a custom build: do you hold the source code, the documentation and the credentials, and could another provider take it over. Ask these questions while you are still a prospect, because the answers are considerably harder to obtain later.

Situations and the Honest Recommendation

Task	Traditional	Decided on Evidence	Notes
Two mainstream systems, standard retail flows	Quoted as a custom build	Use the connector	This is the most common case and custom work here is usually wasted money.
Replatforming within twelve months	Build now, rebuild later	Connector until it settles	Building against systems you are about to replace is expensive learning.
Contract pricing with pack rounding	Managed in spreadsheets	Custom or hybrid	A core commercial rule a generic connector will rarely handle correctly.
Connector covers 80 percent well	Replace it entirely	Keep it, add a thin layer	The hybrid is frequently the cheapest durable answer available.
A system with no connector available	Manual rekeying forever	Custom, scoped narrowly	Scope to the flows that actually hurt rather than everything at once.
Per order fees at growing volume	Reviewed years later	Modelled at projected volume	Model the fee at the volume you expect, not the volume you have today.
Five systems, not two	Five separate connectors	Assess a central approach	Point to point connectors multiply, and each pair is another thing to maintain.
Connector vendor discontinues support	Emergency rebuild	Exit plan agreed up front	Ask about mapping export and notice periods while you are still a prospect.

Where This Decision Goes Expensively Wrong

Buying a build because the demo did not cover an edge case

A single requirement the connector cannot meet is frequently used to justify replacing it entirely, when the sensible response is to check whether that requirement is core, whether the vendor has it on a roadmap, whether a small custom layer alongside the connector would cover it, or whether the process could reasonably change. Commissioning a full custom build to solve one exception means giving up vendor maintained reliability on everything else, and taking on maintenance for flows that were working perfectly well.

Choosing a connector without testing your real data

Connectors are demonstrated on clean sample data and your data is not clean. Before committing, trial it with a realistic extract including your awkward cases: products with unusual unit of measure, orders with mixed tax treatment, customers with several delivery addresses, bundles, and anything with special characters or legacy codes. Most connector disappointments are discovered in the first month of live trading and would have been visible in a fortnight of proper testing with genuine records.

Ignoring what happens at your volume

Pricing that is comfortable at a hundred orders a day can be uncomfortable at a thousand, and Australian retail volume is strongly seasonal, so the relevant figure is your peak rather than your average. Check how the connector behaves as well as what it costs at peak: throughput limits, queuing and how it handles a burst are all worth asking about specifically. A connector that becomes a bottleneck during your busiest fortnight is a problem precisely when you can least afford one.

Not knowing who owns the custom build

If you do commission custom work, settle ownership in the contract rather than assuming. Who holds the source code and the intellectual property, where the documentation lives, whose accounts hold the credentials and the hosting, and could a different provider reasonably take it over. Custom integration where the developer holds everything is not an asset, it is a dependency, and the time to fix that is before the work starts rather than during a dispute.

Comparing against a build that was never properly scoped

Build quotes obtained without a written requirement tend to be optimistic, because the developer has priced what they imagined rather than what you need. Comparing a subscription against an under scoped build price makes custom work look closer in cost than it will prove to be. Scope the requirement properly first, then obtain comparable pricing for both routes against that same document, and expect a well scoped build to cost more than the first number anybody mentioned.

Assuming a connector removes the need to understand your data

A connector will happily and reliably synchronise data that is wrong. If nobody has decided which system owns price, or your product codes do not match between systems, a connector will propagate those problems faster and more consistently than a person would. The ownership decisions still need making, the identifiers still need aligning, and the reconciliation still needs someone watching it. Buying rather than building changes who maintains the code, not whether your data model needs to make sense.

How Yes AI Approaches Build or Buy

We will tell you to buy when you should buy

A meaningful share of the enquiries we take are better served by a packaged connector and some configuration help, and we say so. We would rather give away a build than sell you one that leaves you worse off and blames us for it in two years.

A written comparison you keep

The assessment produces a requirement list marked against connector capability, a three year cost comparison in AUD at your projected volume, and a recommendation with the reasoning shown. It is yours to act on however you choose, including without us.

Hybrid designs where they fit

Where a connector covers most of the need, we will scope the smallest custom layer that closes the gap rather than proposing to replace what works. This is frequently the cheapest durable answer and it is rarely the one being quoted elsewhere.

If we build, you own it

Custom work runs on a managed cloud automation layer we operate and monitor, with documentation, credentials and the ability to hand over to another provider included as standard rather than as a negotiation. Our monthly fee is for support, not for holding your systems.

Making the Decision Properly

Five steps, typically two to three weeks. Most of it is deciding what you actually need rather than evaluating products.

Write the requirement down

What must flow, in which direction, how often, and what the business rules are. Separated into things you cannot trade without and things you would prefer. Vague requirements produce misleading quotes from every direction.

Assess connectors against it

Checking documented capability rather than sales claims, including how your awkward cases are handled, what the pricing does at your projected volume, and what support looks like in Australian trading hours.

Trial with your real data

A sandbox run using a realistic extract with your genuine edge cases included. This is where most of the truth emerges, and a fortnight here regularly prevents a costly decision in either direction.

Cost both routes over three years

Subscriptions and per record fees at projected volume, build and hosting, internal workaround time, change work, and the cost of exit on each side. Compared in AUD on the same requirement.

Decide, and plan the review

Choose the option, including a hybrid if that is the answer, and set a point to revisit it, typically at a volume threshold or a platform change. The right answer today is not permanently the right answer.

FAQ

How do we know whether we have outgrown a connector?

The clearest signs are practical rather than technical. Someone is spending regular hours each week correcting or completing what the connector produced. You have built spreadsheets that sit between two systems because neither the connector nor the platforms handle a rule you depend on. The connector cannot see a system that has become important to you. Its per transaction pricing has grown into a material line item. Or its data model genuinely cannot express something central, such as your pricing structure or your multi entity arrangement. One of these alone usually means adjust or supplement. Three or more together generally means the fit has broken down.

Is a custom integration always more expensive?

Not over a long enough period, though it usually is at the start. A custom build concentrates cost up front with lower ongoing fees, while a connector spreads cost through a subscription that typically rises with volume. Where a business is growing quickly and paying per order, the lines can cross sooner than people expect. That said, custom work carries ongoing costs many comparisons omit: hosting, monitoring, and the change work needed as connected platforms update their interfaces. Compare over three years including those, and be sceptical of any build quote that shows no ongoing cost at all, because that cost exists whether or not it is in the proposal.

What is a hybrid approach and when does it make sense?

A hybrid keeps the connector for the high volume standard flows it handles reliably and adds a narrow custom layer for the specific things it cannot do. Examples include applying a pricing rule the connector cannot express before records reach the commerce platform, feeding an additional system the connector does not support, or enriching records in transit. It makes sense whenever a connector covers most of your requirement well and the gap is identifiable and contained. You keep vendor maintained reliability where the volume is, and you pay for bespoke work only where it is genuinely needed, which is usually a fraction of a full build.

What should we ask a connector vendor before committing?

Ask how your specific awkward cases are handled and request a sandbox trial with your real data rather than their sample set. Ask what happens when one of the connected platforms changes its interface, who fixes it and how quickly. Ask what the pricing is at two or three times your current volume, and whether it is per order, per record or flat. Ask what their support hours are in Australian time and what their response commitment is during a peak trading period. Finally, ask what leaving involves: whether you can export your field mappings and cross reference data, what notice is required, and what happens to records in flight.

Does a connector mean we do not need to worry about data quality?

The opposite, if anything. A connector will synchronise incorrect data reliably and at speed. If product codes do not align between systems, if nobody has decided which system owns the selling price, or if customer records are duplicated, a connector will propagate all of that faithfully and faster than a person ever would. Deciding data ownership, aligning identifiers and setting up reconciliation are needed whichever route you take. Buying rather than building changes who maintains the code, not whether your underlying data model is coherent.

We already paid for a custom build that is not working. What now?

Resist the instinct to immediately commission another one. Start with an assessment of what exists: whether the requirement was ever written down, whether the build actually fails to meet it or was built to a different understanding, whether the code and documentation are in your possession, and whether the problems are architectural or a matter of unfinished work. Quite often a working system needs correction and proper monitoring rather than replacement, and sometimes a connector could take over the bulk of the traffic with the custom piece reduced to a small remainder. Either way the assessment is cheap relative to rebuilding twice.

How long is this decision valid for?

Treat it as a decision with a review date rather than a permanent one. Volume growth changes the cost comparison, particularly where per transaction fees apply. Replatforming changes which connectors exist and what they cover. Business model changes, such as adding wholesale alongside retail or opening physical stores, can introduce requirements no connector anticipated. A sensible approach is to set a specific trigger for revisiting, such as reaching a volume threshold or changing a core system, and to keep the requirement document current so the next assessment starts from evidence rather than from scratch.

Get an Answer From Someone Willing to Say Buy

Book a call. We will assess your requirement against what connectors actually do, cost both routes over three years, and tell you honestly which one you need.