An app built on our platform is, at bottom, a configuration — a description read against an engine that all apps share. And that configuration is written in a vocabulary the platform defines: the section types. Articles, events, videos, products, forms. A section type is a word in the platform's language. This article is about what it costs to add one. From the outside, adding a section type looks like building a screen and shipping it. It never is. The difference between a feature and a word is that a feature gets used, while a word has to be understood — by everything that reads the language. Until every reader understands it, the word doesn't exist; there's just a screen with a secret. Everyone who reads the language Take the events section — on paper, a calendar of what's coming. Here's who has an opinion about it the day it's born. Navigation has to know how to route to it and back out of it. The design system has to know how to dress an event — and not in one app's theme, in every theme any app might wear: an event card has to look deliberate in a minimal text-first design and in a photo-heavy one, because the word belongs to the whole language, not to the app that inspired it. Push has to be able to announce one: a new event should be able to notify subscribers exactly like any other content, without the push system containing a single line specific to calendars. Links have to reach it: an event needs an address that a shared post — or a printed flyer — can carry, and that address has to keep working long after the event itself scrolled off the screen. If the app runs the chatbot, events become material for answers: "what's the best show for a first visit?" is now a question the app is expected to handle based on its content. If an agent operates the app, creating and editing an event has to be an operation an agent can perform. And before any of that, the back office has to exist: someone has to write events — forms, fields, dates that end after they start. Each of those is a question the new word has to answer before it's allowed into the language. The calendar screen — the thing that looked like the whole job — is one line on the invoice. The matrix grows in both directions Here's the part that compounds: a word added is a word maintained, and the grammar grows both ways. Every new word has to be understood by all existing readers — that's the invoice above. But every new reader has to understand all existing words. The day we plugged a chatbot into apps' content, it couldn't just handle whatever section type was fashionable that year; it had to read the whole language, every word ever added. The day agents arrived, same story: operating an app means operating all of it. The true price of a word was never the feature work of its launch season. It's the row and the column of that matrix — paid once when the word is born, and again every time the language gains a reader, forever. A lighter way to say something new That price would be unbearable if it were the only option. It isn't — and this is where the economics of a platform get interesting. Not every need deserves a word. When one app needs something bespoke, a section can be described and generated for that app alone. The generated section lives in a slot the platform already understands: navigation knows how to reach it, every theme knows how to frame it, and nothing anywhere else has to learn a thing. The price stays small for exactly that reason — it teaches nobody anything. Which is also the honest statement of what it doesn't buy: it's a local phrase, not a new word. One app speaks it; the language hasn't changed. So there are two prices, and they're honest about what they purchase. The small one is local: the need is served today, for the app that has it. The full one is universal: every subsystem learns the word, and every app on the platform can use it, forever. A bespoke need lives comfortably at the small price. When the same need keeps arriving from different directions, it's telling us it wants to be a word — and then we pay the full price, knowingly. The invoice is the feature Because here's what the full price buys. Once the platform has learned a word, it works everywhere the language is spoken: every app can add an events section and inherit — with zero additional work, theirs or ours — the navigation, the theming, the push, the addresses, the answers. An extra screen works where you put it. A word works everywhere, for everyone, from then on. That's what "adding a feature" actually means on a platform, and why it bears no resemblance to shipping a screen. The price of a new word is what makes it a word.