The Schema Is the Skeleton, the Network Is the Bloodstream

Every few months somebody shows me a demo that would have taken a team a quarter to build five years ago, and they built it over a weekend. I'm not cynical about that. It's real, and I use the same tools.

But it changes what I pay attention to. If the code is the cheap part, what's still expensive? I keep landing on the same two things. The first is the shape of the data: a modular, schema-first model that the rest of the product hangs off. The second is the people already standing around the product before it ships: customers, partners, resellers, integrators, and the industry relationships that will carry it into the places it needs to go.

My short version: the schema is the product's skeleton, and the network is its bloodstream. A product with good bones and no circulation doesn't move. A product with circulation and bad bones collapses the first time it has to carry weight.

Building got cheap, so look at what didn't#

The cost curve is not subtle. Epoch AI's analysis of LLM inference prices found that the price of reaching GPT-4-level performance on PhD-level science questions fell by about 40x per year. Across the different performance milestones they tracked, the declines ranged from 9x to 900x per year. They're careful to say the fastest drops are recent and less certain. Even the slow end of that range is a dramatic change in what it costs to produce working software.

When something gets that cheap, it stops being a moat. Your competitor can build what you built. So can your customer, sometimes. What they can't easily copy is years of well-structured data, or the trust of the people who buy, install and recommend things in your market.

The bottleneck shows up in how companies are actually doing with AI. In February 2025, Gartner reported that 63% of organizations either don't have, or aren't sure they have, the right data management practices for AI, based on a survey of 1,203 data management leaders. Their prediction was blunt: through 2026, organizations will abandon 60% of AI projects that aren't supported by AI-ready data.

That isn't a model problem. It's a schema problem.

What I mean by schema-first#

Schema-first just means you decide what things are before you decide what screens show them. You name the entities, their fields, the relationships between them and the rules they must obey. Then the interface, the API, the reports and the integrations all derive from that one definition instead of each inventing their own.

I build this way on my own work. Design tokens describe the visual language once, and every component reads from them. A single unified data model sits under the product, and the UI, the API and the exports are views of it rather than separate copies. It's slower in the first week. It's faster every week after that, because each new feature is a new arrangement of parts that already exist and already agree with each other.

Modular is the other half of the word. A good schema is made of pieces that can be recombined: a customer is a customer whether they show up in billing, support or analytics. The pieces have clear edges, so you can swap one implementation without breaking its neighbours.

You can see the pattern in products that became infrastructure. Stripe's API reference reads like a data model with a company attached: customers, payment intents, subscriptions, invoices, each a well-defined object with stable relationships. Developers learn the nouns once and compose them. In its 2024 update, Stripe said it processed $1.4 trillion in total payment volume, up 38% year on year and roughly 1.3% of global GDP, and that half of the Fortune 100 now use it. I won't claim the object model is why Stripe won. Plenty of things went into that. But I don't think you get to be plumbing for that many businesses with a muddy data model.

The industry is already voting for this#

The best evidence that schema-first works is how much of the industry has quietly moved toward it.

Postman's 2025 State of the API report, which surveyed more than 5,700 developers and API professionals, found that 82% of organizations have adopted some level of API-first approach, and 25% describe themselves as fully API-first, up 12% from the year before. API-first is schema-first wearing a work badge: you define the contract, then build both sides to it.

The money follows. In the same report, 43% of fully API-first organizations said APIs generate more than a quarter of their revenue, compared with 23% of somewhat API-first organizations and 16% of those that aren't API-first. That's a correlation, not proof that API-first causes revenue. Companies with valuable data are more likely to expose it through APIs in the first place. Still, it lines up with what I've watched happen: clean contracts make a product easier to sell through other people.

There's also a warning in that report. 89% of developers say they use AI, but only 24% design their APIs with AI agents in mind. The next wave of consumers of your data may not be people at all, and a vague schema is even harder for a machine to use correctly than for a human.

The network I mean is not network effects#

When I say "network," I need to be precise, because the word is overloaded.

I don't mean network effects, the product mechanic where each new user makes the product more valuable for the others. That's real and powerful. NFX has argued that network-effect businesses account for roughly 70% of the value created in tech since 1994, based on a study of 336 companies. They're open that the numbers are an estimate, not a scientific result. But that's a property you design into a product and then hope you reach critical mass.

What I mean is something you either have on day one or don't: an already-established business network. The customers who trust you. The partners who integrate with you. The resellers, consultants and systems integrators who sell and implement your category. The people across your industry who will take your call. That network doesn't come from the product. It carries the product.

Most software reaches customers through someone else#

It's easy to forget how much of the technology market is sold through intermediaries. Canalys estimated that channel partners would account for 73.2% of the total IT market in 2024, out of roughly $4.94 trillion in worldwide IT spending, as reported by Channel Post MEA. Nearly three quarters of the market moves through partners: resellers, distributors, managed service providers, integrators.

That changes how I think about building. If most products reach customers through partners, then the partner is a user too. They need to understand your product quickly, connect it to what their clients already run, and deploy it repeatedly without calling you every time. A clean, modular schema is what makes that possible. A messy one turns every implementation into a custom project, and partners stop recommending things that eat their margin.

This is where the skeleton and the bloodstream meet. The network decides whether the product reaches customers. The schema decides whether it survives the trip.

Relationships carry more value than cold reach#

The research on relationships is less flashy than the research on AI, but it's steady.

On referrals, the most rigorous study I've read is by Schmitt, Skiera and Van den Bulte, published in the Journal of Marketing in 2011 (PDF). They followed about 10,000 customers of a German bank. Customers who came in through referrals had higher margins at first, though that gap shrank over time. They were more likely to stay, and that difference lasted. Overall, referred customers were worth at least 16% more than similar customers acquired other ways. The effect varied by segment, so it isn't a law of nature. But it's a real, measured premium on arriving through someone you trust.

On fundraising and survival, Shane and Stuart studied all 134 firms founded between 1980 and 1996 to commercialise MIT-assigned inventions. Ventures whose founders had direct or indirect ties to venture investors were more likely to raise venture funding and less likely to fail. They called founders' social capital "an important endowment." That's the established network showing up in the data before the company has much of a product at all.

Distribution can beat a better product#

The starkest example I know is in an antitrust file.

In September 2025, the European Commission made Microsoft's commitments binding in the Teams case, which began with a complaint from Slack in July 2020. The Commission's preliminary findings, which Microsoft disputed, were that bundling Teams into its productivity suites distributed it automatically across hundreds of millions of existing seats. The decision notes that Microsoft's own internal documents recognised the importance of that distribution advantage. And it says Teams' advantage "does not seem to be explained by any substantial quality advantage in the eyes of Microsoft's customers."

Microsoft agreed to offer suites without Teams at lower prices, improve interoperability for rivals and make data easier to export. You can read that as a story about market power, and it is. I also read it as the extreme version of a truth every builder runs into at a smaller scale: being already installed, already trusted and already on the purchase order beats being slightly better.

The honest complications#

None of this is a guarantee, and I don't want to oversell it.

Buyers are more independent than they used to be. Gartner found in 2025 that 61% of B2B buyers prefer a rep-free buying experience overall, and 73% actively avoid suppliers who send irrelevant outreach. If your idea of a network is a big list of cold contacts, that's bad news. But the same survey found buyers still want seller input for the hard parts, like deciding whether something actually fits their company. That's where a trusted relationship earns its keep. The network that matters is the one people want to hear from.

A network also can't rescue a product that doesn't work. It just gets the bad news to you faster. And a beautiful schema with no one to carry it is an engineering hobby. I've built a few of those.

The pairing is the point. Either half on its own is ordinary.

What I'd do with this#

Model the nouns before the screens. Write down the entities, fields and relationships first, and make every surface derive from that definition.

Design for the implementer, not just the end user. Assume a partner you've never met will deploy your product for a client you'll never talk to. Make the data model legible enough that they can.

Map the network you already have. Before building, list the customers, partners and peers who would carry this into the world, and ask them what they'd need. If that list is empty, that's the real first project.

Treat clean data as an asset on the balance sheet. It compounds. Every feature, integration and AI workflow you add later gets cheaper because of it.

The takeaway#

When building is cheap, the durable advantages are the ones that took time: a data model that knows what things are, and relationships that know who you are. The schema is the skeleton. The network is the bloodstream. Get both, and the code on top is the easy part.

One thing nags at me, though. If everyone eventually holds well-shaped data and a loyal network, the natural instinct is to protect both. I suspect that instinct is already reshaping the web, and not entirely for the better. More on that next.