Draw your backend, read exactly what would be built, deploy it in one transaction. Then open the screen everybody else makes you build yourself: your users, columns you added, the licence each one bought, and what the database will actually hand them.

No, and that is the part worth the money. Every other backend hands you a list of users with a delete button, which is why every product ends up writing its own internal tool — a week nobody scoped, never finished, and the least reviewed code in the building.

You get a grid you actually work from. Ban and unban, verify an address, correct one, grant a role, sign somebody out everywhere — in place, in the row.

The columns are yours. plan, credits, trial_ends, referred_by — declare what your product tracks about a person and it is typed, validated and sorted like anything else. New columns are private to your server unless you deliberately let users edit them, because a credits column your own customers can write is not a feature.

And their licence is already on the row. A licence is issued to an email address and a user has one, so nothing needs wiring up: suspend it, move the expiry, or free every machine it is stuck on, from the row of the person who wrote in.

Draw a table on the canvas, press Deploy, and it is queryable straight away. There is no schema file to keep in step — the API reads the live columns, so a column you add is queryable immediately and one you drop stops being.

From an app it is one package:

const authsy = createClient(url, publishableKey);

await authsy.auth.signUp({ email, password });
await authsy.from('notes').insert({ body: 'mine' });

// Only theirs. No filter written anywhere.
const { data } = await authsy.from('notes').select();

Nothing there says “belonging to me”, and it does not have to — the rule on the table decides. Or skip the client: every table is at /db/<name> with filters that read as ?status=eq.paid&order=created_at.desc, about a minute to learn and the same shape for every table.

Real SQL against real tables. Indexes, joins, foreign keys, JSON columns you can query into, transactions that actually roll back — not a document store with a query language painted on, and not a subset that runs out the first time you need a join.

Every row is readable back out over the same API that put it in, paged, with no export ticket to file — and what it comes out of is an ordinary table in an ordinary schema, not a format you have to escape from later. Isolation is enforced by the database rather than by a filter in a query builder, so the guarantee survives a bug in the layer above it — that is the one thing here you could not have written yourself in an afternoon.

Because you can look. Every tool in this space will tell you a policy exists; none of them tells you what it does, which is why “the policy looks right” is how row security fails.

The access review puts on each caller’s identity in turn — nobody signed in, a signed-in stranger, the user who owns the row — asks the database what each one can read, write and delete, and rolls all of it back. What you get is a table of measured numbers, not an opinion about your SQL, and it names anything worth acting on: a table anyone with your shipped key can read, a rule stricter than it looks, row security switched off.

The same question, asked of one person, is on their row in the users table: what they own, beside what the database will actually hand them. When those two numbers disagree, the rule is not doing what it looks like — and no amount of reading the policy would have told you. Looking cannot write: the database refuses it, rather than the page promising not to.

Every response is HMAC-signed with your tenant secret and echoes a nonce you generate, so a replayed or hand-crafted "valid" doesn't verify.

That raises the cost of cracking considerably, but nothing running on someone else's machine is unbreakable — treat it as a strong lock, not a guarantee. Validate on your own server wherever the architecture allows it.

They keep working. Licenses can be issued as Ed25519-signed files your app verifies locally, and offline grace tokens cover a period away from the network.

Paying customers shouldn't be locked out by a dropped connection — that's the fastest way to turn a refund request into a chargeback.

The database, storage and the canvas are on every tier, free included — nothing in the deploy or data path checks a plan. What the tiers price is monthly active users on the licensing side, never keys or seats.

Free covers 2,000 users on one product; Indie is $9/mo for 10,000 across three; Studio is $29/mo for 50,000 across ten. Go over and it's ＋$5 per 1,000 extra users rather than a forced upgrade.

Yes. Connect your own Stripe, take crypto, or point any processor at a signed custom webhook — a verified payment issues the license automatically, and repeats can't double-issue.

Authsy Pay is the alternative if you'd rather not run that yourself: hosted checkout and payouts at 2.9% + 30¢ per charge, with no monthly fee.

You have one. That is the product: tables and JSON collections you design on a canvas, deployed into a schema of the project’s own, reachable over REST straight away.

Your app also gets its own users — sign-up, sign-in, sessions — separate from your Authsy account and from every other project. Each table carries a rule saying who may read a row: nobody but your server, each user their own rows, any signed-in user, or anyone. It becomes a policy in the database when you deploy, so select() returns that user’s rows without a filter you had to remember, and keeps doing so for the endpoint somebody adds next year.

And you get somewhere to look at it. The users table lists the people, the columns you added about them, and what each one can actually reach — so “where has my order gone” is a search, not a query you write against production.

Being honest: it is a separate product that happens to live on the same account. A Luau decompiler — control-flow lifting, semantic naming, automatic deobfuscation, a Dex-style explorer and live capture from an executor.

It shares the account and the licensing layer, so a licensed app of yours can call the same engine through the client API instead of you hosting one. Free runs with checkpoints; Pro is $12/mo.