What an AI-built app costs per editor

The sticker price of a platform for AI-built sites is almost never the number that ends up mattering. The one that matters is whichever number starts moving when the site does well: the client adds a second editor, or the members' area passes a thousand accounts, or a post gets shared somewhere and the traffic turns up on a Sunday when nobody's watching.

There are three of those meters in this category, and I'll go through each of them, what it does to an agency running a lot of client sites, and then what the bill looks like on a platform where none of them run. That platform is mine, so read the last part with that in mind.

#The per-editor meter

This is the one everybody sees. A content platform charges per seat, and a seat is anyone who can log in and change something. For one site that's a rounding error. For an agency it's the client's two marketers plus the intern who posts the blog, times fifteen clients, and it's billed to you until you work out how to pass it through. It also quietly shapes the handoff. Agencies under-provision editors to keep the bill down, and that's how the client ends up messaging you to change a heading.

#The per-user meter, which you meet later

You don't run into this one until the site has an audience. Platforms that host the app as well as the content will often cap the number of accounts the app itself can have, meaning the people who sign in to a members' area, a customer portal, a community. A cap of a thousand accounts sounds generous on launch day. Then a client portal hits it, or a course site, or one event with a lot of invitations, and the fix is a tier change or a second instance.

#The per-view meter, which is the big one

This one barely shows on the invoice as a line and it's the largest. If every page view runs code, every page view costs something, forever, whatever the unit is called on that platform's pricing page. The thousandth visitor to a page that hasn't changed costs the same as the second. Some platforms make this structural: an app built by their agent can't be served as static files, so every request hits a container. A post that does well is also a bill.

They compound, too. Picture an agency with fifteen client sites. It's paying for the editors it under-provisioned. Two of the sites grew and hit their account cap. And underneath all of that is a compute bill that tracks how well the clients are doing rather than how much work the agency did.

#What a bill looks like when none of them run

Tessryx charges for three things, and none of them is any of the above.

Workspace seats, for the people who build and edit inside the Tessryx app. That includes the content forms the schema generates, so a client contact who wants to edit there takes a seat, and each plan includes a fixed number. Where this differs from meter one is that the seat isn't the only editor. The agent can build an admin into the site itself, and the people who use that are app users: unlimited on every plan, the free one included, and never a seat. Give a client's whole team the site's own editor and it costs the same whether they have two editors or twelve, twenty members or two thousand.

Custom domains, a fixed number per plan, with more available on the Pro and Agency plans without changing tier. A new client site is a domain, not a new subscription.

Executions, which is the one meter that does run, so I'll be exact about it. A credit pays for a workflow run. That's a page render, an API call, a scheduled job, a test run in the editor, or the agent calling something over MCP, however it got triggered. What separates this from per-view pricing is caching. A cached page is served from the edge without running anything, and cached views are free. A public page with a cache window serves its thousandth visitor for nothing, because nothing runs. The docs put a small, well-cached marketing site at a few hundred credits a month against a Pro allowance of a hundred thousand. Media and published data serve from a CDN with no bandwidth charge. Building, drafting, editing and saving never use credits at all.

And there's no line for the AI, because you bring the agent you already pay for.

#What does cost

Two things do cost, and an agency should plan around them.

Pages that can't be cached. A gated page is never shared-cached, because one person's private view must not be served to somebody else. So a members' area, a personal dashboard or an admin page runs on every visit and costs a credit each time. The right structure is the obvious one: keep the public parts public and cached, and gate only what actually needs gating. Credits and caching covers the mechanics.

Running out. Credits are prepaid, and running out stops executions across the workspace until you top up. What keeps serving in the meantime is the cached pages and the published data, which for a well-built site is most of it. Nothing gets deleted and nothing is owed. There's no overage bill, which I know some people would prefer to the alternative, but I'd rather a site go quiet than a client get a surprise invoice.

#The arithmetic for an agency

Take one client site. A marketing site with a blog, a gated members' area, three editors on the client side, and a couple of thousand members.

• Editors: three, using an admin the agent built into the site. Unmetered.
• Members: two thousand. Unmetered.
• Public pages: cached, so views are free until the cache expires and one render refreshes it.
• Members' pages: one credit per visit, because they can't be cached.
• Domain: one.
• Seats: your two builders, in whichever workspace they build in.

Multiply by fifteen clients and the only lines that grew are domains and the members' page renders. The editors and the accounts didn't move the bill at all, because none of them needed a seat, and the public traffic barely touched it.

Plans and the full limits table are on the pricing page and in Plans and limits.