This Is Too Hard to Build

The last practical objection is the most honest one in the series, and it almost always comes from somebody who has tried. Grant the diagnosis. Grant the governance. You are still left with a distributed-systems problem of the ugliest kind: messy inputs, adversarial participants, incomplete information, latency, and trust that has to be earned rather than assumed. The engineer who has watched ambitious manufacturing platforms die concludes it is simply too hard to build, and I do not think that person is being lazy or cynical. I think they are right about the difficulty and wrong about what follows from it. Claim: the difficulty of building a manufacturing coordination layer is the reason to build it rather than a reason to walk away, because a coordination system this hard becomes durable infrastructure the moment it exists; the path is to turn the smallest coordination loop first and compound it, not to launch complete, and the failure mode is boiling the ocean before a single loop has turned.

There are two kinds of hard. A problem that is hard because it is pointless should be dropped quickly and without ceremony. A problem that is hard because it coordinates an entire industry is a moat — whoever solves it ends up owning infrastructure the next entrant has to rebuild from zero.

The objection at its strongest

The graveyard is real, and it was well funded. Covisint, the online parts exchange founded by General Motors, Ford, and DaimlerChrysler on something like a half-billion dollars of investment, was beset from the start by "the failure of big car companies to agree on anything," and by 2004 its assets sold for roughly seven million dollars. Chemdex, a business-to-business marketplace carrying a seven-billion-dollar market capitalization at the height of the dot-com bubble, shut its exchanges and was trading at thirty-nine cents a share by 2001. And the underlying difficulty is measurable, not just cultural: a NIST-commissioned study found that imperfect interoperability — the plain fact that data files are not usable across the systems that need them — imposed "at least $1 billion per year" on the U.S. automotive supply chain alone. Anyone telling you this is hard is telling you the truth.

Why the difficulty is the moat

Hard coordination problems, once solved, become the infrastructure everyone else quietly stands on, and the payoff compounds for decades. Containerization took roughly twelve years of "winding and political" negotiation to reach a workable standard, and the reward, in the causal estimate of Bernhofen and colleagues, was a cumulative increase in trade among industrialized countries on the order of seven hundred percent over twenty years — an effect the authors found larger than all the free-trade agreements and the GATT combined. The internet required a forced cutover, the TCP/IP flag day of January 1, 1983, after which noncompliant hosts simply lost access. Visa now clears more than two hundred billion transactions a year across more than two hundred countries. SWIFT carries more than fifty-three million messages a day, enough that in its own description, "roughly every three days, the world's GDP passes over our network." Not one of those was easy, which is precisely why each became load-bearing and nearly impossible to dislodge.

The cold-start reality

The specific hard part is the cold start. A coordination network has little value until it has participants, and participants do not show up until it has value. That is not a reason the thing cannot be built; it is a specification for how it has to be built. Value has to exist for the very first buyer and the very first supplier, before any network effect arrives, which rules out every design that leans on scale to be useful. The systems that crossed this gap delivered standalone value at the atomic unit and let the network compound on top of it. None of them waited for universal adoption to switch on.

The governed design

So you start with the smallest loop that produces value all by itself. Take one messy inbound request, structure it, route it to one verified supplier, capture the outcome, and write that outcome back so the next routing decision is better than the last one. That loop is useful to exactly one buyer and one supplier with no network whatsoever, and it is the seed — identity, reputation, and routing all improve with every job that runs through it. Fallbacks belong in the design from the first day rather than arriving later as an apology for it, because a system built for the messy tail will absolutely meet inputs it cannot resolve, and when it does it has to degrade into human review instead of breaking. The control point is that the minimum viable loop delivers value before the network exists, which means difficulty gets paid down a little at a time rather than all at once on launch day.

Operational test

The claim is falsifiable by how the thing is built and whether it actually compounds. Does the smallest loop — one request, one verified supplier, outcome written back — create value at a scale of one, before any network effect? Are the signals that are supposed to compound actually compounding, with repeat-award rate rising and response time falling as the record thickens? Does the system meet imperfect input with a graceful fallback rather than a failure? A project that has to be complete before it is useful is repeating Covisint. A project that is useful at a scale of one and compounds from there is building the moat.

Implications

Treat difficulty as a verdict and the critic is right by default: the problem stays unsolved because every reasonable person declines it, which is a fair description of why it is still unsolved. Treat difficulty as the moat and the same hardness that killed the underfunded and the impatient becomes the durable advantage of whoever turns the first loop and keeps turning it. No country gets an industrial coordination layer by wishing the problem were easier. It gets one because somebody decided the hard version was worth a decade of their working life. The practical failure mode is boiling the ocean — the launch that has to be complete before it works, and therefore never works. That exhausts the objections, which leaves one thing left to do. Forty papers in, I owe you the rules: what all of this is supposed to protect, written down somewhere it can be checked. The final paper is the industrial constitution.

Questions to Ask

1. Does our smallest coordination loop create value at a scale of one, before any network effect?
2. Which signals are supposed to compound, and are they actually compounding with each job?
3. When the system meets input it cannot resolve, does it fall back to a human or break?
4. Are we trying to launch complete, or to turn one loop and grow it?
5. What durable advantage accrues each time the loop runs that a new entrant could not copy?
6. Is the difficulty we are paying down the kind that becomes a moat, or the kind that is just cost?