--- title: "Five years in, we finally have the right word for what we are" url: https://apyhub.com/blog/five-years-in-we-finally-have-the-right-word-for-what-we-are author: Samuel Kaluvuri published: 2026-07-13T23:00:00Z tags: [first principles] --- # Five years in, we finally have the right word for what we are This month, ApyHub turns five. Five years is a long time for a bootstrapped startup — especially one that spent most of it building something the industry kept calling by the wrong name. We answered to "API marketplace" because it was the closest label available. The real thing took too long to explain. Today we're done borrowing that word. What we've built over five years isn't a marketplace. It's infrastructure for how software is now composed and consumed — by both humans and agents. ## We priced for reality, not convenience Early on, we made a decision most people found strange: dynamic pricing per call based on the actual work performed. Not flat fees. Not credits. Just the real cost of each request. The logic was straightforward. A trivial call and a heavy one are not the same product. Charging the same price for both isn't simplicity — it's one customer subsidising another. The market pushed back. There were stretches where we seriously considered rolling it back to the flat-fee model everyone expected, just to stop having the same argument. Instead we held on, and explained it customer after customer. Then large language models arrived and the entire industry started billing by the token. The principle we'd spent years defending suddenly became obvious to everyone. That was the first clear signal we were building for a different future than the one most platforms were optimising for. ## We chose a different relationship with providers and customers Most API marketplaces let every provider set their own plans, tiers, and billing. We went the opposite direction. One subscription for the customer. Revenue distributed to providers based on actual consumption — like Spotify. It was unconventional. Providers had to trust us with pricing and revenue share. Customers, however, understood it immediately: one relationship, one bill, the full catalogue. At the time it felt like a billing decision. In hindsight, it was the moment we stopped being a marketplace. A single subscription across an entire catalogue isn't how marketplaces work. It was the first real hint of the layer we were becoming. ## The marketplace model was built for a different era Marketplaces solve discovery and procurement. They aggregate offerings, simplify sign-up, and route calls. That model was designed for humans browsing at design time — evaluating, comparing, integrating slowly. Software has moved on. Increasingly, capabilities are composed at runtime rather than integrated at design time. Applications and agents discover what they need and call it in the moment. The old model doesn't stretch far enough into this world. You can't retrofit your way into it, either. Bolting an MCP endpoint onto a decade-old marketplace doesn't make it ready for how software gets built today — it just puts a modern label on a legacy model. The reality underneath has to change. So ours did. ## This is the layer, not the shelf Every major shift in software creates a new layer — one company that absorbs a messy, repeated problem and turns it into infrastructure everyone builds on. Payments were a thicket of processors and bank integrations until Stripe became the payments layer. Communications meant wrangling carriers and telecom contracts until Twilio became the messaging layer. Code collaboration was scattered until GitHub became the collaboration layer. Each one replaced "every team solves this themselves" with "everyone builds on this." APIs have reached that point. Every team is solving the same integration, billing, latency, and trust problems over and over again — which is usually the moment a new layer appears. We think APIs need what payments eventually got: a distribution and consumption layer. A piece of infrastructure that sits between the people building capabilities and the software using them, handling everything except the capability itself. I want to be precise about that, because "distribution and consumption" can sound like a marketplace wearing a nicer suit. It isn't, and the difference is the whole point. A marketplace improves the *commercial* relationship. It makes discovery easier and billing simpler — but underneath, you're still managing separate plans, keys, and limits for every provider. And it stops at procurement: when a call is slow or fails, the performance of that call was never really its concern. That's the provider's problem. The layer owns the whole path — commercial and technical. One subscription across the entire catalogue, usage-based metering, revenue distributed to providers automatically. And increasingly, providers deploy onto infrastructure we operate rather than list an endpoint they run themselves — which is what lets us place a capability in a region close to the caller, stand behind real service levels, and answer for latency and uptime ourselves. You can't move an endpoint closer to someone if you don't run it. The test is simple: when a call is slow, or something breaks at 3am, whose problem is it? A marketplace points at the provider. A layer owns it, because the call was running on its infrastructure the whole time. That's not a rename — it's a different position in the stack. From the directory you check before you build, to the infrastructure you depend on while you run. ## What this release formalises That shift is what today's release makes official. We opened publishing to any builder with a capability worth shipping. Point at your endpoint and we handle the rest — docs, billing, gateway, distribution. You build the capability; we run the machinery around it. The reason most excellent, narrow capabilities never break through was never the capability. It was everything around it. That's the part we want to carry, so builders can stay builders. We added a US region alongside the EU, so calls run closer to the applications making them. We rebuilt the gateway to absorb the spiky, highly parallel workloads that modern agent-driven systems create — one task fanning out into hundreds of calls, absorbed instead of rejected. And we shipped a native MCP server, built on a deliberate choice about discovery. You don't load the entire internet into your head to search it — you ask when you need something. Agents should work the same way: an agent's attention is finite, and a thousand unused tool descriptions leave less room to think. So rather than hand an agent the whole catalogue up front, we followed the search-and-use pattern — the same approach Anthropic uses — where the agent searches for the exact capability it needs and calls it at runtime. ## We didn't predict the future. We built for it. None of these choices were obvious when we made them. Each one looked like unnecessary friction at the time. Over five years they compounded into something coherent — and after enough strange decisions turn out right, you stop calling it luck. You were building for where the world was going, while everyone else built for where it happened to pay that year. We were never trying to win the API marketplace game. We were building the layer underneath it — the one through which composed software and agents discover, select, and consume capabilities through a single, dependable relationship. Five years ago we started with a simple belief: developers should spend their time building great products, not stitching together infrastructure. Providers should focus on the capabilities only they can build, not on becoming accidental SaaS companies. We're still building for that belief — only now we have the right word for what we've become. This is the distribution and consumption layer modern software runs on. And we're just getting started.