We don't build cathedrals.

A cathedral is a strange thing to hold up as a warning. Chartres, Cologne and Florence's own Santa Maria del Fiore are among the most durable pieces of infrastructure human beings have made. They are still in use. And that is the point I want to start from, because the way I have used the word on the Foundation's pages, "empty cathedrals hoping people will come", gets the history backwards in a way that turns out to be instructive.

Real cathedrals were built for congregations that already existed. Florence started the Duomo in 1296 because the old church of Santa Reparata could no longer hold the city; the building was a response to demand the city could measure on a Sunday. The nave was in use for decades while the dome stood open. The works were run by the wool guild and paid for by the city, which needed the building and taxed itself for it. The cathedral came after the congregation, was built by the people who would use it, and was used before it was finished.

The empty cathedral, the one I actually mean, is the opposite object: a structure raised on a hypothesis about a congregation that may one day arrive. Most of what the last decade called infrastructure in Web3 is this second kind. I want to say why, what the inversion looks like, and where it has already worked three times outside crypto, before anyone in crypto thought of it.

I. The cathedral problem

Every piece of infrastructure faces the same bootstrapping problem. You need users to justify building it, and you need it built to attract users. There are two honest ways through: build small and let use pull the next piece out of you, or build the whole thing on a guess and hope. The second is what I call the cathedral problem, and the tendency is structural rather than a failure of individual judgement.

The order of operations is wrong. The traditional Web3 sequence is protocol first, adoption hoped for. A team designs a general-purpose system in isolation, raises money against the design, launches with a token and a conference talk, and then goes looking for the problem the system solves. The defect sits in the sequence, rarely in the code: the infrastructure arrives before the problem it is meant to serve, so nothing has ever put it under load. It has never had a user who would be harmed if it failed.

The incentives reward the drawing, not the building. A protocol is financed on its whitepaper. Its value is set on the day the token lists, months or years before a single transaction that anyone needed. That prices the architecture and never the use. A team paid for the drawing will draw. It will over-architect, because a more ambitious drawing raises more, and it will generalise, because a system that could serve anyone sounds larger than a system that serves someone. Both instincts produce buildings nobody enters.

The feedback arrives too late to matter. A cathedral raised on a guess finds out whether the guess was right when it opens. By then the capital is spent and the design is fixed. There is no cheap correction available, so the team defends the design, and the ghost town gets a roadmap.

The pattern has a body count. The large majority of protocols launched between 2017 and 2022 have no measurable use today. Their code was often fine. They were designed in isolation, launched with fanfare, and faded, because they were answers written before the question.

Outlier Ventures' "Pathways to the Post-Web" thesis, which I discuss in the Manifesto, offers two routes: decompose existing institutions into machine-readable primitives, or constitute new systems from first principles. The first meets institutions that do not wish to be decomposed. The second is the cathedral problem stated as a strategy. I did not find a third path in the literature, so we built one.

II. The inversion

The inversion is a change in the order of operations and nothing more exotic than that. Problem first, protocol second. Pick a venture that must solve a real problem for real users, one that cannot ship its product without a piece of sovereign infrastructure: verified identity, programmable trust, value exchange without a gatekeeper, governance without a boardroom. Let that venture build the piece because it has to, inside its product, for customers who will notice if it fails. Then, once the piece has survived contact with production, extract it, standardise it and make it public.

Three things change when you run the sequence this way.

The infrastructure is specified by necessity. A venture does not over-architect its own plumbing. It builds what it needs, as small as it can, because every unneeded feature is a week it does not spend on customers. The result is smaller than a cathedral and, on the day it is extracted, already correct in the one way that matters: it does the job someone was paying for.

The infrastructure is tested by stakes. A component embedded in a product that people depend on gets tested by their dependence. Real transactions, real failures, real 3 a.m. incidents. By the time it is lifted out and standardised, it has a history of load nobody could have simulated. The Manifesto puts it in a table: designed from scratch on one side, battle-tested before extraction on the other. The whole argument is in that row.

The adoption is guaranteed from day one. This is the part that matters most for public infrastructure and the part hardest to buy any other way. The venture that built the component already depends on it. The day it becomes a public protocol, it has at least one serious user, and that user is the one who knows it best. A cathedral opens to an empty nave. A harvested component opens with its congregation inside.

The cost of the inversion is honest and I will state it: the venture may fail. A builder we back may run out of money or market before the component is ready to be harvested. That is a real risk and it is a different one from the cathedral's. A venture that fails leaves a component that at least someone needed. A cathedral that fails leaves a drawing.

The mechanic the Foundation runs on this principle has three steps, plant, grow and harvest, and the Foundation's own page describes them; I will not re-explain them here. The Harvest Model© is the name the Foundation gives to the whole sequence. The idea underneath it is older than the name, which is the next section.

III. Three times this already worked

I did not invent the inversion. I noticed that the most durable infrastructure of the last twenty years was made this way, by companies that never set out to make infrastructure at all.

Amazon, then AWS. Amazon spent the early 2000s solving its own problem: an online store growing faster than any internal system could keep up with. It built storage, compute and queueing for itself, under the load of its own Christmas traffic, because it had to. Then it noticed the pieces were general. S3 opened in March 2006 and EC2 in August of the same year. The cloud was harvested from a bookshop. It now carries roughly a third of the world's cloud infrastructure and a large part of the internet with it. Nobody wrote a whitepaper for the cloud. A retailer's plumbing turned out to be the protocol.

Tiny Speck, then Slack. Stewart Butterfield's company was building an online game called Glitch. To build it, the team wrote themselves a chat tool, because the tools that existed did not fit how they worked. Glitch shut down in December 2012. The chat tool was the part that had been under load, and it became Slack in 2013. Salesforce bought it in 2021 for $27.7 billion. The product that was supposed to be the cathedral failed. The thing the builders needed in order to build it was the infrastructure.

The Collison brothers, then Stripe. Patrick and John Collison were not trying to build the payments layer of the internet. They were two developers who found it absurdly hard to accept a card payment in an application, in 2010, and wrote seven lines of code to fix the problem they had. The problem was general because they had it honestly. Stripe processed its first trillion dollars in a year in 2023. It is the payments infrastructure of a large share of the software economy, and it began as a fix for friction its founders felt personally.

Three companies, three industries, one sequence. A real problem under real load, a component built out of necessity, an extraction after the fact. None of them was financed on the drawing. Each of them was tested by dependence before it was offered to anyone else. And each is now more durable than any protocol launched with a token in the same years, because each had a congregation before it had a nave.

There is one more thing the three have in common, and it is the detail that makes the sequence repeatable rather than lucky. In each case the moment of extraction was visible from inside. Amazon's engineers could see that storage and compute had become general because they had watched teams inside the company reuse them. Tiny Speck knew the chat tool was the durable part because it was the part they could not stop using after the game was gone. The Collisons knew the seven lines were general because every developer they showed them to asked for access. Extraction is a decision taken on evidence of dependence, and dependence is the one thing a cathedral built on a guess can never show you.

The precedents also say something about scale that I want to make explicit. AWS, Slack and Stripe were harvested by the companies that built them, and the harvest made those companies large. The Foundation's version of the sequence changes one thing: the harvested components are made public, as open protocols, rather than kept as a moat. Whether that is a better bargain for the builder is a question of alignment, and the Manifesto's last section is about it. The mechanism of the harvest is the same either way.

IV. Where the harvest lands

The reason to invert the sequence is not that it is clever. It is that a closing window does not leave time to build cathedrals and wait. The companion essay makes the case that 2025 to 2030 is Florence's 1450s and that the infrastructure of the agent economy will be fixed, by path dependence, before the decade is out. If that is right, the only infrastructure that will exist in time is infrastructure that is being used while it is built.

That is what the Foundation's programme is for, and its pages say what it does and commits to; I will keep to what I can see from where I sit. Thirteen ventures, in seven groups, each with a problem and a user. Two are in production as I write. Kerubim writes code and proves it correct, with formal verification rather than testing, for a market where "probably works" is not an acceptable answer; the proving infrastructure it needs to exist is exactly the kind of component that gets harvested. ai3.studio develops an idea through a structured conversation with a team of AI agents and assesses the founder by the interaction itself; the evaluation engine it runs on is a second. The rest are at the planning or proof-of-concept stage, each chosen because it cannot ship without a piece of the stack.

Where a harvested component lands is the set of open protocols the Manifesto calls the stack, and what lands there first will be whatever a venture needed first. That is the discipline. We do not decide in advance which cathedral to build. The ventures decide, by needing something, and we notice.

The Duomo was raised for a congregation that had outgrown its church, by guilds that taxed themselves to pay for it, and it was in use for decades before Brunelleschi closed the dome. That is the cathedral I would build. The other kind, the one raised on a guess and opened to an empty nave, we leave to the people who like drawing.

We don't build cathedrals hoping people will come. We choose builders, and from their solutions, we harvest the stones.

The forge is lit.

Ex Fucina, Nexus.