Pricing without seat tax

A backend does not become more valuable because more people have a login.

The people, applications, and agents using a backend may change. The backend itself is still the system being operated.

So why price the backend by seats?

Seat taxes train teams to ration access. A Backend Platform should price the surface you actually run.

This article is about pricing philosophy for an AI-era Backend Platform — not a claim that LUNO is cheaper per seat than every competitor. For the category, see /blog/what-is-ai-era-backend-platform. For why backends should stop being rebuilt, see /blog/never-build-backends-again.

Why seats became the default

Seat-based pricing is not always wrong. For collaboration software, project management, CRM, and many internal tools, the number of people using the product often correlates with value.

Traditional SaaS learned a simple meter:

Traditional SaaS
    ↓
How many people use it?
    ↓
Seats

That meter worked when the product was mostly humans clicking in one UI.

Why seats make less sense for backend platforms

A backend platform supports applications, websites, APIs, data, content, forms, storage, and automation. Its value is closer to what backend is being operated — and what that backend enables — than to how many humans log into Console.

Backend Platform
    ↓
What system are you running?
    ↓
Site / Project / Organization / Usage

Seat-based pricing charges for who can use the backend. A Backend Platform should charge for the backend you run.

Console users are an interface audience. They are not the main resource being consumed.

Seat tax changes behavior

“Seat tax” does not mean “seat pricing is always bad.” It means teams start restricting access because every additional person increases the bill.

"Should we invite them?"
        ↓
"Do they really need access?"
        ↓
"Can one person do it instead?"

The question stops being “Who can make this system better?” and becomes “Who is worth paying for?”

When designers, developers, marketers, editors, product managers, and AI agents all need the same backend, rationing seats optimizes billing — not the system.

The best platform should make access easier, not make teams negotiate access.

AI agents break the seat abstraction

Before agents, a backend looked human-centric:

Backend
 ├── Developer
 ├── Editor
 └── Admin

In the AI era, operators multiply:

Backend
 ├── Developer
 ├── Editor
 ├── Admin
 ├── AI Agent
 └── Application

Agents may help with development, content operations, data operations, testing, and deployment. Then the awkward question appears:

If an AI agent can do the work of several people, how many seats is it?

Is an agent one seat? One seat per agent? One seat per hundred operations? Seat is a poor abstraction for machine-operated infrastructure.

This is not an argument that AI replaces people. It is an argument that seat is a human-centric abstraction — and agents make that abstraction less useful.

The backend—not the person—is the unit

How agents operate that backend through MCP is /blog/operate-luno-from-mcp. Why Console, API, and MCP must share one record is /blog/console-and-api-same-record.

LUNO exposes multiple interfaces to one backend:

                 LUNO Backend
                      │
       ┌──────────────┼──────────────┐
       │              │              │
    Console          API            MCP
       │              │              │
     Human       Application       Agent

The Console is an interface. It is not the product boundary.

Ten people opening Console and one production backend being operated are different concepts. Pricing should move toward the latter.

That does not mean AI agents should always be free. Agents still drive usage: API traffic, storage, bandwidth, automation, execution. The mistake is confusing charging for usage with charging for identity.

Better proxies
- Usage
- Storage
- API requests
- Automation executions
- Bandwidth
- Environment / project scale

Weak proxy
- Number of people who happen to access the Console

What should a Backend Platform charge for?

A useful pricing model looks at both value and cost.

Value

- applications powered
- backend capabilities provided
- development time saved
- infrastructure ownership avoided

Cost

- storage
- API traffic
- compute
- execution
- bandwidth
- operational resources

Seat count alone rarely expresses either side well for a backend platform.

In practice, a Backend Platform should tend to charge for:

1. The backend being operated
2. Resources actually consumed
3. Scale and usage
4. Capabilities that create meaningful value

The number of humans who need access to their own infrastructure is a weak primary unit.

How LUNO approaches pricing

LUNO’s commercial unit is the backend being operated — primarily per site, and per organization for Agency.

Free, Solo, Standard, and Business are priced per site. Agency is priced per organization with included sites. That matches how backends are deployed.

Plans still include team-seat allowances for Console collaboration. Those allowances are capacity within a site/org plan — not the core story of buying another human login as the product itself.

LUNO is not trying to win by charging less per seat. It is trying to choose a better unit for pricing a backend platform.

Free is meant as a real backend you can evaluate before committing to paid infrastructure — including MCP, embed, forms, and the public API — not merely “limited access for one user.” Exact limits live on the Pricing page.

See current plans and limits: https://luno.rest/en/pricing

When seat-based pricing still makes sense

Seat-based pricing can make sense for collaboration software. It is simply not the right default abstraction for a backend platform.

Enterprise deals may still involve support, SLA, security, compliance, dedicated environments, and governance. Those are real pricing dimensions. They do not require turning every backend operator into a metered human seat.

Conclusion

The unit of a collaboration product is often the person.

The unit of a backend platform is the system.

AI makes this distinction even clearer.

Humans use the Console.
Applications use the API.
Agents use MCP.

They all operate the same backend.

So LUNO does not start with:
"How many people will use it?"

It starts with:
"What backend are you running?"

Price the backend. Not the people around it.

Never build backends again means the platform absorbs repeated backend work. Pricing should follow that same unit — the backend platform being operated. More on that mission: /blog/never-build-backends-again.

LUNO is Backend Platform for the AI Era. Humans, applications, and AI agents share one backend. Pricing starts from the system you run.

See plans: https://luno.rest/en/pricing