When You Need a Real Backend, and When You Do Not

"No backend required" is a claim this industry makes loosely, and we are part of that industry. So here is the honest version.

For a separate operational perspective on how teams organise and measure work, workforce optimization software.

For independent background and broader industry context, see Supabase.

You almost certainly need a backend. The question is how small it can be.

The six questions

1. Do you need to trust a value?

Prices, balances, permissions, scores, quotas, anything a user benefits from changing.

If the client can write it, the client can lie about it. No amount of client-side validation changes this, because the validation runs on the attacker's machine.

Yes → backend. Not negotiable, and this is the one people most often talk themselves out of.

2. Do you need to hold a secret?

Third-party API keys, payment credentials, anything you would not print on a poster.

Anything in client code is public. Minification is not obfuscation and obfuscation is not secrecy.

Yes → backend, even if it is one function that proxies a request.

3. Do you need to decide who may access what?

Any multi-user product does.

This is why the token endpoint exists. It is the smallest possible backend — authenticate, authorise, mint a token — and it is the piece that makes shared state safe. See the three authentication methods.

Yes → backend, and it may genuinely be twenty lines.

4. Do you need to query?

"All orders this month", "documents matching this", "users who have not logged in".

Addressing by id does not answer these, by design. See Durable Objects.

Yes → a database, and something to query it.

5. Do you need a durable record?

Orders, transactions, audit trails, anything that must exist tomorrow and be reconcilable.

Live shared state is not a system of record. It is the layer that makes things appear immediately elsewhere.

Yes → backend.

6. Do you need to do something when a user is not there?

Scheduled work, email, webhooks, reacting to a third-party event.

A browser that is closed does nothing.

Yes → backend.

What "no backend" honestly means

Not that there is no server. It means you are not building and operating one for this particular capability.

A shared state service means you do not build a WebSocket tier — connection management, reconnection, presence, broadcast, scaling. That is genuinely months of work avoided.

It does not mean your product has no server. For anything with users, money or trust, it does.

And we should say that plainly, because the alternative is people shipping something with prices in client-writable storage.

The smallest useful backend

For a product using shared state:

A token endpoint. Authenticate, authorise per object, mint. Twenty lines.

A write path for anything trusted. Server-side writes with direct credentials for values users must not control.

Your existing database for the durable record.

That is frequently the whole thing. Not zero, and much smaller than a real-time backend.

Where genuinely no backend works

Being fair to the claim.

A prototype, where nothing is trusted and nothing is secret.

A single-user tool with no accounts.

A public collaborative toy — a shared whiteboard where there is nothing to protect and no identity to establish.

Documentation widgets — a poll on a docs page, where the worst case is a skewed count.

Static sites with a small shared feature and no user data.

In these, direct credentials in the client are a real option, because there is nothing behind them worth having.

The test

Ask: if a user opened devtools and changed this, would it matter?

No → client is fine.

Yes → it goes on your server, and no client-side arrangement substitutes.

That question resolves nearly every case, and it is worth asking about each value rather than about the product as a whole.

The short version

You almost certainly need a backend. The question is how small.

Six triggers: trusted values, secrets, access decisions, queries, durable records, and work while the user is away.

"No backend" means you are not building a real-time tier — not that your product has no server.

The smallest useful one is a token endpoint plus a trusted write path, which is small.

And the test is: if a user changed this in devtools, would it matter?