Point-to-point integrations or unified commerce: deciding where your stock’s source of truth lives

You have two systems that argue about stock, and a connector between them costs a few thousand and a fortnight. It fixes the pain, so you buy it. That is the correct call at two systems. The trouble is that the connector you just bought is not the last one, and the quote you should have been looking at is not this one. It is the one that arrives at system four, when a new tool has to talk to three others and every connector you add multiplies the ones already running. Point-to-point vs unified commerce is not a best-practice question with one right answer. It is a cost-curve question, and which curve is cheaper depends on how many systems you will run in three years, not how many hurt today.

Most of what ranks for this comparison is written by companies that sell one of the two answers, so the honest version is hard to find. This piece is the honest version: what each approach actually costs as you scale, where the source of truth ends up living in each, a plain both-sides matrix, and a rule for choosing that does not assume you should buy the expensive thing. Flatline builds both point-to-point integrations and unified stacks, so the advice here is not the sale. It is the trade-off as it actually behaves across real stacks.

What each approach is, and where the source of truth sits

Point-to-point integration connects two systems directly so one can read or update the other, wiring each pair together for a specific purpose. Unified commerce is an architecture where your systems share one connected data layer, so every channel reads and writes to a single record instead of keeping its own. The first is a set of direct wires between systems. The second is a shared centre that the systems all connect into.

Here is the reframe the vendor pages skip: both approaches can have a single source of truth. A source of truth is a governance decision about which system holds the authoritative number, and you can make that decision inside a point-to-point setup just as you can inside a unified one. In a point-to-point stack you might designate the ERP as the master for stock and have every direct wire treat it as authoritative. The real difference between the two approaches is not whether a source of truth exists. It is how many connections you have to build and maintain to keep that source of truth honest, and how that number grows as you add systems.

That is the whole decision, stated plainly. The question is not “connected or fragmented.” It is “how many connectors will you own in three years, and where does the master live.” Once it is framed that way, the choice stops being ideological and becomes arithmetic.

The criteria that actually decide this

Five criteria decide the choice, and cost-as-you-scale is the one that flips the answer. Upfront cost, cost as you add systems, where the source of truth lives, maintenance and fault isolation, and time to the first working fix. Most comparisons weigh only the first and the last, which is why they make point-to-point look like the obvious budget option. It is the budget option, right up until the second criterion overtakes everything else.

Upfront cost is what you pay to get the first integration working. Cost as you scale is what you pay for each additional system you connect, and it is where the two approaches diverge sharply. Source-of-truth location is which system holds the authoritative record and how directly every other system reaches it. Maintenance and fault isolation is what happens when one connection breaks: does it take down one link or ripple across the stack. Time to first fix is how fast you can resolve the one integration that hurts right now. Hold these five in mind, because the honest comparison is just these criteria applied without a thumb on the scale.

Point-to-point vs unified commerce, criterion by criterion

On upfront cost point-to-point wins, and on cost-as-you-scale unified commerce wins, and the crossover between those two is the entire decision. A single point-to-point connector is cheap and fast. A unified platform or a central integration layer is a large fixed cost you pay before the first benefit arrives. If the comparison stopped at day one, point-to-point would win every time. It does not stop at day one.

The reason cost-as-you-scale flips it is arithmetic you can check. If every system needs to talk directly to every other, the number of connections for a fully wired stack is n times (n minus 1), divided by two. Two systems need one connection. Three need three. Four need six. Five need ten. Six need fifteen. The systems grow in a line while the connections grow in a curve, and each connection is a separate piece of bespoke work that has to be built, tested, and maintained on its own. Most real stacks are not fully wired, so the true number sits below that ceiling, but the shape holds: connectors grow faster than systems, and every one you add is another thing that can break independently and another line on the maintenance bill. This is the cost the brief’s “system four” names. It is not that the fourth system is special. It is that the fourth system is where the curve starts to outrun the line.

Unified commerce inverts the shape. Each system connects once to the shared layer, so connections grow roughly in step with systems rather than ahead of them. You pay heavily up front for that layer, and in return the per-system cost of every future addition stays flat. On source of truth, point-to-point can hold one but has to enforce it across many separate wires, so it drifts more easily as the stack grows. A unified layer holds it centrally by design, which is why unified setups keep the record consistent as systems multiply. On fault isolation the trade runs the other way: a broken point-to-point wire usually takes down one link, while a problem at a central layer can affect everything reading from it, which is the risk you accept in exchange for the flatter cost curve.

Choose point-to-point if, choose unified commerce if

Choose point-to-point if your stack is small and stable: two or three core systems you do not expect to keep adding to, one connection that resolves the pain, and no roadmap that multiplies integrations over the next few years. In that situation the connector is not a compromise. It is the right-sized answer, and buying a unified platform would be paying a large fixed cost to solve a problem you do not have. Spending platform money on a three-system stack is its own kind of wrong call, and the vendor pages never mention it.

Choose unified commerce if you will run many systems, or if your three-year plan keeps adding them: new sales channels, more locations, a separate B2B motion, marketplaces, a subscription engine. When the system count climbs, the connector-multiplication cost overtakes the platform cost, and the flat per-system curve is what saves you. The decision variable is the count of systems you expect to be running in three years, not the count causing pain this quarter. A stack of four systems today that becomes nine by 2028 should be planned around the nine. Deciding on the four is how brands end up rebuilding the whole integration layer eighteen months after they paid for the connectors.

The honest read is that most brands mis-time this rather than mis-pick it. They choose point-to-point correctly for where they are, then keep choosing it past the point where the curve crossed, because each individual connector still looks cheap in isolation. The cost never announces itself in a single invoice. It accumulates across a dozen of them.

The edge cases: hybrids and the middle path

The middle path is usually the right answer for growing mid-market stacks: a central integration layer that gives you unified commerce’s flat cost curve without replatforming onto a single native system. Rather than wiring every system to every other, you route them all through one event-driven hub or integration layer that holds the source of truth and propagates changes outward. You keep your best-of-breed systems and still get the single centre that stops the connector count from exploding.

This is what a real unified build tends to look like in practice. When Flatline connected OGÉR’s Shopify Plus, POS, ERP, and WMS into one coordinated structure, the point was not to collapse everything into one product. It was to give the systems a defined centre to defer to, so online and offline read the same record. A hybrid also covers the case where most of your stack is stable but one corner changes often: keep the stable systems on direct wires and route the volatile corner through a layer. The strategic case for unifying is real once scale justifies it, but the layer, not a full native replatform, is where most mid-market brands should start.

When to revisit the decision

Revisit the decision the moment your system count crosses the threshold you set, not on a fixed calendar. Whichever way you choose, the choice is correct only for a range of stack sizes, and the range you are in changes as the business grows. Write down the count at which you would switch, and treat crossing it as the trigger to re-evaluate, the same way you would revisit any decision whose right answer depends on a number that keeps moving.

The practical signals that you have crossed it are consistent: you are building a new connector every quarter, a single system change forces edits in several places, or you spend more time keeping integrations alive than using the data they move. When those appear, the point-to-point stack that was correct at four systems has quietly become the expensive option, and the layer you skipped earlier is now the cheaper one. Catching that shift early is worth more than getting the first choice perfect, because the first choice was always going to be temporary.

If you are mapping your source-of-truth options, this is the decision to get right before you buy connectors. Flatline is a Shopify Platinum Partner that builds both point-to-point integrations and unified stacks, so we can look at your three-year system count and tell you which curve you are actually on. Get in touch and we will walk through it with you.

Frequently asked questions

What is the difference between point-to-point integration and unified commerce?

Point-to-point integration connects two systems directly with a dedicated link for a specific purpose. Unified commerce connects all systems into one shared data layer they each read and write to. The practical difference is how connections grow: point-to-point adds a new wire for each system pair, while unified commerce adds one connection per system to a central record.

Is point-to-point integration cheaper than unified commerce?

It is cheaper up front and for a small, stable stack, and more expensive as you add systems. A single connector costs little and works fast. But point-to-point connections grow faster than the number of systems, and each is maintained separately, so past a certain system count the accumulated cost overtakes a unified platform’s larger fixed price.

Does point-to-point integration give you a single source of truth?

It can. A single source of truth is a decision about which system holds the authoritative record, and you can enforce that inside a point-to-point setup by designating one system as the master. The difference is that point-to-point enforces it across many separate wires, so it drifts more easily as the stack grows, while a unified layer holds it centrally by design.

When should you move from point-to-point to unified commerce?

Move when your three-year system count is high or climbing, not when today’s stack hurts. The trigger signals are practical: building a new connector every quarter, one system change forcing edits in several places, or spending more time maintaining integrations than using them. When those appear, the connector-multiplication cost has overtaken the cost of a central layer.

Is unified commerce always better?

No. For a small, stable stack of two or three systems you do not plan to expand, unified commerce is over-engineering: you pay a large fixed cost to solve a problem point-to-point already handles cheaply. Unified commerce wins when system count is high or growing. Below that threshold, direct connections are the right-sized choice.

Key takeaways

• Point-to-point vs unified commerce is a cost-curve decision, not a best-practice one. The right answer depends on how many systems you will run in three years.
• Both approaches can hold a single source of truth. The real difference is how many connectors you maintain to keep it honest, and how fast that number grows.
• Point-to-point wins on upfront cost and speed to first fix. Unified commerce wins on cost-as-you-scale, because connections grow in step with systems instead of ahead of them.
• Point-to-point connections grow faster than the systems they link. That curve, not any single invoice, is the cost the “system four” moment names.
• The common error is mis-timing, not mis-picking: choosing point-to-point correctly, then holding it past the point where the curve crossed. Write down the system count at which you would switch, and revisit when you cross it.

The mismatch you are trying to end is downstream of this choice, which is why it is worth making deliberately rather than one connector at a time. Get the source-of-truth decision right, size it to the stack you will have rather than the one you have, and the integration spend stops being a series of surprises and becomes a curve you chose on purpose.