The build-vs-buy reality.

Picture the room where this decision gets made. Product leader, engineering lead, maybe the CTO. The third or fourth enterprise customer just asked whether the platform can onboard their 14 trading partners. The honest answer right now is "not yet." The question on the table is whether to build the B2B connectivity capability or find a partner who already operates the network.

Everyone in the room is a good engineer. The APIs involved do not seem esoteric. The trading partner protocols are documented. The team has shipped harder things. A plan forms. Six months, three engineers, a v1 that handles AS2 and SFTP for the partners this first customer needs. Iterate from there. The room is aligned.

Here is what that framing misses. B2B connectivity is not an engineering problem that gets solved. It is an operational system that has to keep running. Through certificate expirations at 3 AM. Through partner spec changes nobody warned you about. Through compliance requirements that shift once a year and the protocol coverage creep that every platform eventually hits. The build is not the hard part. The decade of operation that follows is the hard part.

This deep dive is about what that decade looks like for the platforms that chose to build. Why the economics do not close for most of them. Why the pattern is consistent enough that it shows up across unrelated companies with different engineering cultures. And why the decision is not really "build or buy," even though that is the name it takes in the conference room.

The plan looks reasonable on the whiteboard. Pick the initial protocols (usually AS2 and SFTP). Pick one or two trading-partner integration patterns. Get the first partner onboarded end-to-end in a test environment. Demo it to the first customer. Iterate from there.

This works. For about four months.

Then the first real customer arrives with their partner list. That list contains the partners in the test plan plus eight others. Three are retailers with spec variations that were not in the plan. One is a 3PL that uses a proprietary file-naming scheme. One is a marketplace with its own SDK. The team says "we will handle these in sequence." The customer's onboarding timeline, which was 30 days in the signed contract, slips to 90. Sales promises it will be faster for the next customer.

Customer two arrives with a different partner list. Three partners overlap with customer one and work on day one. The other nine require new builds. The pattern is now visible. Every new customer brings a long tail of net-new integrations. The team tries to build abstractions. The abstractions hold for the center of the distribution and break at the edges. The backlog of "partner-specific quirks" becomes a distinct engineering domain with its own Jira label. The team that was going to ship the feature that differentiates the product is still writing trading partner connectors at month 18.

This is the pattern. Not an exception. Not a team that made mistakes. Not an architecture problem a better senior engineer could have avoided. The pattern.

The outcome metrics that track with this path are consistent enough to almost predict. The six-month build becomes an 18-to-24-month build. The team that started at three engineers grows to three to five full-time engineers maintaining what they built, plus a portion of a product manager, plus devops time, plus a support manager handling escalations. And the cost of each new connection stays roughly the cost of the first one, because nothing about the architecture compounds.

The failure modes of self-built B2B connectivity are not a matter of opinion. They show up on specific weeknights, for specific reasons, to specific engineers. The texture matters, because "operational load" is an abstraction until you are the one carrying it.

Certificate management, on a Sunday night

Sunday, 11 PM. An AS2 certificate for one of your three biggest trading partners expires Monday at 3 AM Pacific. The engineer who set up the rotation schedule left last quarter. The runbook says "run the renewal script," but nobody on the current team has run it in production, the partner's contact on the other end is a group alias that responds on weekdays, and the old root cert pinning in the partner's firewall is about to reject a non-identical replacement. Every AS2 partner is a version of this scenario waiting to happen. For 10 partners, it is a spreadsheet and a calendar reminder. For 100, it is a dedicated operational burden. For 1,000, it is a full-time job.

Partner spec variation, compounding quietly

A retailer updates their 850 purchase order validation. The update lands in a spec bulletin emailed to a distribution list nobody on your team is on. Your integration keeps working for 11 weeks, and then the retailer starts rejecting documents on the 12th because a formerly-optional field is now required. Every retailer's 850 follows the X12 standard except in the three or four places where it does not. Building for five retailers is buying five slightly different purchase-order handlers. Building for 100 is operating a partner-specific validation matrix the team keeps in sync with dozens of implementation guides that change without notice.

Non-repudiation, in the audit

A customer hands you a compliance audit. The auditor asks for signed receipts from a transmission that happened 14 months ago. The team's answer, "we archive the files," turns out not to be a compliant response. AS2 MDN chains, signed receipts, audit trails, and document archives sound like a week of work on the whiteboard. The actual compliance requirement is that every receipt be cryptographically verifiable and retrievable in a format the auditor recognizes, years after the transaction. The gap between "we kept the file" and "we kept a verifiable signed acknowledgment chain" is the whole job.

Protocol coverage, creeping outward

Year one plan: AS2 only. Year two: SFTP, because the biggest new customer runs on it. Year three: Peppol, because two European customers need it and the e-invoicing regulation is live. Year four: a customer whose largest trading partner still uses X.400, and the team discovers there are only a handful of engineers left in the industry who remember X.400 well enough to debug a failed handoff. Every protocol added is an operational domain the team has to stand up, staff, and keep fluent in. Nothing in the original plan accounted for this curve.

Operational cost, the quiet one

By month 18, the "integration project" has become a department. Transaction volume monitoring. Throughput anomaly alerting. SLA compliance tracking per partner. Exception queues. Failed transaction reprocessing. End-user visibility requests. Each is a week of work to ship and a permanent operational cost to maintain. None of it differentiates the product. All of it has to keep working, because any of it going sideways breaks production for paying customers. This is where the build-it-ourselves decision stops feeling like a decision and starts feeling like gravity.

Most build-versus-buy decisions skip the part where someone writes down the actual cost of building. It is worth doing. A fully-loaded senior engineer in a competitive market costs approximately $250,000 a year once benefits, tools, equipment, and management overhead are included. An 18-month B2B connectivity build with three engineers is approximately $1.1 million before a single trading partner is onboarded.

That is the initial cost. The ongoing cost is where the math gets uncomfortable. Steady-state, a production B2B connectivity operation inside a platform company runs three to five full-time engineers, plus a portion of a product manager, plus devops, plus a support manager who handles escalations. That is $750,000 to $1.25 million per year, every year, for as long as the integration exists. Over five years, the all-in cost of an internal build and maintenance operation is $4 million to $6 million. For that investment, the platform gets infrastructure that does not compound, does not generate network effects, and does not differentiate the product the platform actually sells.

The number most decision-makers miss is the opportunity cost. Those three to five engineers were a selection from the strongest on the team. The B2B connectivity project is staffed with seniors because it has to be. Those seniors were not spending those five years on the platform's differentiated product surface. They were not building the analytics layer that retains customers through renewal. They were not shipping the onboarding experience that wins enterprise deals against competitors. They were rotating certificates and debugging MDN chains.

On a competitor platform that bought instead of built, the same engineers were on product. That platform's feature velocity looked different. Its sales cycle was shorter because connectivity was not the long pole. Its enterprise win rate was higher because it could promise 30-day onboarding and keep the promise. The gap between the two platforms after five years is not a connectivity gap. It is a product gap, compounded by five years of engineering attention going to different places.

The most common pushback on this argument is a version of the same objection. We are not trying to connect to hundreds of partners. We have five. Our use case is simpler. The five places the internal build breaks do not apply to us at our scale.

The problem with the objection is not that it is wrong on the day it is made. It is wrong on the day it stops being true, and that day is usually one the team did not plan for.

Partner drift

The five partners you started with become seven once sales closes the next enterprise deal. Seven becomes 11 once procurement asks whether you can support their three logistics partners. 11 becomes 25 once the company makes an acquisition that comes with a partner base attached. Every platform that is growing has partner drift. The only platforms that do not are the ones that have stopped growing.

Compliance ratchet

Retail trading partners expand their compliance requirements on an annual cycle. The validation rules that were optional last year are mandatory this year. The signed acknowledgment that was a best practice is now an audit finding. Every partner's compliance bulletin is a potential change request the internal team has to absorb. The ratchet only goes one direction.

Marketplace expansion

The DTC customer wins a marketplace deal, which turns out to require a specific flavor of EDI nobody on the team has implemented before. The learning curve for a new protocol or format is the same whether you are supporting one partner or 50. Once the team is onboarding a new protocol for one customer, the marginal cost of supporting it across the rest of the customer base is low. Which is exactly why it happens, and happens again, and compounds.

The simple integration is only simple in the timeframe the team scoped it in. Over five years, every integration trends toward the complexity of every other integration. The structural answer does not change with scale. It just becomes more obvious.

The argument against building internally is not absolute. For a specific profile of company, building is the correct call. Naming that profile matters, because platform leaders sometimes assume they fit it when they do not.

Build internally if your platform is the network. If you are Amazon or Walmart or a hyperscaler whose identity is being the destination thousands of other companies integrate into, the B2B connectivity layer is core to your competitive position and the economics work because you are the center of the graph. Building in that position gives you control of the connectivity standard for your ecosystem. Buying would mean outsourcing the surface your customers interact with.

Build internally if the regulatory isolation is extreme. There are categories — specific government contract tiers, specific defense applications, specific healthcare workloads — where the connectivity layer has to run inside a compliance boundary so restrictive that even the best shared network cannot cross it. This is rare and usually obvious. If a general counsel and a procurement officer have both explicitly required the connectivity layer be in-house, build.

Build internally if B2B connectivity is the product you sell. If your company is a VAN or an EDI managed-service provider whose customer proposition is the connectivity itself, the work of running the network is the work of running the company. The economics of building are different when the product margin is on the infrastructure you operate, not on the product that sits above it.

Most platform companies do not match any of these three profiles. They sell a SaaS product, a vertical platform, or an application where B2B connectivity is a capability that customers expect in the background. The customer does not pick the platform for its connectivity layer. They pick it for the product the connectivity layer supports. For that profile, building internally is a capital allocation that funds the wrong layer of the stack.

The question is not whether building is ever right. The question is whether it is right for you. If you are honest about the business you are in, the answer is usually clearer than the decision-making process treats it as.

Before B2B connectivity faced this question, other infrastructure layers faced versions of it. The answers have been consistent enough to recognize as a pattern.

Content delivery networks went first. Through most of the 1990s and into the 2000s, web companies at scale built internal caching layers and edge servers. The specific architectures varied, but the shape was the same: a permanent engineering team maintaining infrastructure that was not the product. Cloudflare and Akamai did not replace those teams because they had better technology. They replaced them because the economics of a shared CDN compounded in ways a single company's caching team could not. By 2015, the question "should we build our own CDN" had an agreed industry answer for almost every web company that was not Google or Facebook.

Cloud compute went through the same migration a few years later. Data center operations, virtualization, load balancing, regional failover — the full stack of running production servers — collapsed into AWS, Azure, and GCP for the vast majority of software companies. The argument for internal data centers is narrow and getting narrower. Payments, email delivery, identity, observability, error tracking, API management: every one of these categories went through the same process. A layer that companies built internally became a layer companies inherit.

The characteristics of categories that make this shift are consistent. High fixed cost of entry. Network effects that compound with the number of participants. Non-differentiating to the end product sitting on top of the layer. Every category that has all three eventually consolidates onto shared infrastructure. Not because shared infrastructure is trendy but because the math makes it inevitable.

B2B connectivity has all three characteristics. It has had them for a long time. The category answer has been forming for fifteen-plus years and is mostly resolved in the analyst conversations, just slower to propagate through the decisions platform companies actually make on a Tuesday morning in an engineering review. B2B is late to this answer. That is an opportunity for the platforms that see it early and a compounding disadvantage for the platforms that do not.

Five years into a self-built B2B connectivity strategy, the platform that chose to build is not behind by a sprint or two. It is behind by the shape of the curve. The connectivity cost has grown roughly linearly while the addressable partner universe has grown quadratically. The gap between the two is wider every quarter. More engineers added to the internal team does not close it. The shape of the cost curve does not change with more bodies.

This is the outcome that is hardest to see in the annual budget review. The build cost is a line in the engineering budget. The opportunity cost is invisible. The customer that chose a competitor platform because its onboarding was 30 days instead of 90 is not attributed to the connectivity team's velocity. The enterprise deal that stalled because the partner list could not be onboarded in time does not show up in the connectivity retrospective. The hires that never happened on the product team, because budget was consumed by the connectivity team, do not appear as missing features in a product review.

Meanwhile, on the competitor platform that bought instead of built, the same five years looked different. Its three engineers who would have been on infra are on product. Its onboarding times for new customers are shorter than the category average. Connectivity is a non-issue in sales conversations. The shared network its platform runs on has continued to grow. Every new partner that joined that network joined on behalf of some customer somewhere, and is now available to this platform's next customer at no additional build cost.

Compounding disadvantages are the hardest kind to reverse. They do not announce themselves. They accumulate as a gap that gets easier to tolerate each quarter and harder to close each year. The platform that gets this right in year one runs well into year five. The platform that does not compounds in the other direction and spends the later years trying to catch up to where the network put its competitor by default.

ECGrid is the shared B2B network that platforms build on. We have been operating it for more than 25 years. It is API-first, programmable end-to-end, and architected for platform tenancy rather than for individual trading partners logging into a portal. It is also the rarest kind of infrastructure in our space: the kind that does not compete with the platforms running on it.

That last part matters more than it sounds. Most of the alternatives to building internally come from companies that also sell directly to your customers. Their incentive is to use the connectivity layer as the foothold for a broader product relationship. Ours is not. ECGrid does not sell the product you sell. ECGrid sells the infrastructure layer your product depends on. Your customers stay yours. Your margin on the services you deliver on ECGrid stays yours. The network runs underneath the relationship rather than trying to own it.

What a platform inherits by building on ECGrid is the economic shape of the "joined the network" scenario described above. Most trading partners your customers need to reach are already on the network. The protocol, format, and compliance coverage is already in place. The certificate management, non-repudiation, audit, and SLA infrastructure run at the network layer rather than being rebuilt per platform. The engineering team that was going to spend five years on connectivity can spend those five years on product.

For readers weighing the decision right now, here is the reframe we would offer. The question is not really build-versus-buy. The question is whether your platform is in the business of operating B2B infrastructure or running a product that depends on B2B infrastructure. Most platform companies are in the second business and convince themselves they are in the first because engineering is interesting and building feels like strategy. The category answer has been the same in every adjacent domain. B2B connectivity is late to arrive at it. That lateness is the last window in which the decision is yours to make, before the category makes it for you.