A free tier is a security problem wearing a marketing costume. The moment you let anyone create an account and run code without a card, you've handed the internet a build farm and a place to host whatever they want, on your bill. Most platforms solve this by making the free tier weak and annoying. I wanted ours to be contained instead. It's generous about the one thing that matters and locked down about everything that gets abused.
Here's how the lineup works: Explore (free, no card) → Builder ($10/mo minimum, card on file, and that minimum includes your first $10 of usage) → Enterprise. The interesting design isn't the prices. It's what "free" is allowed to do, and how a single card flips the whole thing open.
Free is a demo, not a tier for real workloads
A new account defaults to Explore, and Explore is a discovery surface, not a place to run a business. One app, from a curated template. No persistent storage. App state goes to a managed database, not a disk you can fill. No custom domains. No REST API, no API keys. No object storage. Conservative build caps. And, enforced at the network layer rather than just in policy, locked egress: a free app can't reach the open internet at all. (Seats, notably, aren't on that list. They're free and unlimited on every plan, including Explore, and uptime is the meter, not your teammate count.)
That last one matters. "Free apps can't make outbound requests" isn't a settings checkbox an attacker can argue with. It's a NetworkPolicy. The abuse playbook for free compute (crypto miners, spam relays, credential stuffers) all needs to phone home. Cut egress at the network and most of it simply doesn't function.
But notice what Explore keeps: the MCP endpoint stays open, and editing your app's source stays open. That's deliberate, because that's the demo. The whole point of the product is watching your agent build and rebuild a real app. Free has to be enough to feel that, or it's pointless. So I kept the magic and locked the margin-burners.
A card lifts the whole envelope at once, in one place
When an account puts a card on file, everything in that contained list flips on together: custom domains, the REST API and keys, object storage, open egress, editable build recipes, arbitrary imports. Not à la carte, not behind six more upgrade prompts. The whole envelope lifts the moment you're a paying account.
The thing I'm most careful about is that this lives in one place. There is exactly one function that says "if this account is paying, OR all these capabilities on." The temptation, every single time you add a new free restriction, is to scatter a little if (free) deny check into the tool that enforces it. Do that a dozen times and you have a dozen subtly different definitions of "free," and one of them is wrong, and that one is a security hole or a billing leak. So new capabilities go into a central entitlements bag, get flipped on in the one resolver, and every tool reads the resolved entitlement, never a hardcoded plan name.
When you say no, say it like an agent can hear it
There's a principle underneath all of this: the deploy loop over MCP stays free. An agent can drive a free app end to end. What's gated is the headless automation surface: the REST API, keys, programmatic access. That split is intentional, but it creates a risk: an agent hits a gate and dead-ends.
So no gate is ever a silent no. Every one returns a machine-readable code, a pointer to a guide the agent can actually read explaining what enables the capability, and a human upgrade link when one's wired. The agent doesn't guess why it was refused. It's told, in a shape it can branch on. A refusal that an agent can't understand is just a different kind of dead-end, and dead-ends are the one thing this product doesn't allow.
Free being heavily controlled isn't a grudging compromise here. It's a feature I'm happy to keep adding to, because a free tier you can safely give to strangers is the only kind worth having.
- Ryan