--- title: "A business app is a database plus permissions" description: "Most internal tools are a database with screens bolted on. Screens are now the cheap part. Who may see which rows and fields is the product." date: 2026-10-06 language: en canonical: https://gtable.app/blog/database-plus-permissions source: gtable blog --- # A business app is a database plus permissions Look at almost any tool a company builds for itself: a CRM, an order tracker, a hiring pipeline, a list of suppliers. Take the screens away and two things are left. The first is a set of tables that point at each other. Deals belong to companies, companies have contacts, contacts have a history. The second is a set of rules about who may do what with them. A salesperson sees their own deals. A manager sees the team's. Finance sees the amounts, and nobody else does. Everything else is a preference. One person wants a board, another wants a list sorted by date, a third wants a chart on Monday mornings. Preferences change every month. The tables change slowly. The rules hardly change at all, and when they are wrong, somebody sees something they should not have. gtable is built on that observation. The database and the permissions are the product. Everything else is a way of looking at them. ## Screens are cheap now. Rules are not. For a long time the expensive part of an internal tool was the interface. Every new view was a ticket, and a team waited weeks for a dashboard. That is no longer true. An assistant can write a decent screen in a minute, on real data, in the shape the person asking actually wants. So the hard question moved. It is no longer "can we build this view?". It is "may this person, or this person's agent, see this data at all?". And that question has to be answered the same way everywhere. If the grid hides a column but the export includes it, the column is not hidden. If the API checks permissions but the search box does not, the search box is the API. If an agent reaches the data through a service account that can read everything, every rule you wrote is a suggestion. ## One compiler, every surface In gtable, a group's permissions are compiled into two things for each table: a filter that decides which rows exist for a person, and a mask that decides which fields do. That pair is applied by everything that reads data. The grid uses it, the REST API uses it, the MCP server uses it, the assistant uses it, and so do the screens people build. There is no second path to the data, so there is no second thing to get wrong. *Diagram: One permission compiler sits behind every way of reaching an app's data.* Three properties come out of that, and they are the ones that matter day to day. **Absent, not hidden.** A field you cannot read is not greyed out or blanked. It is not there: not in the row, not in the API document that describes the table, not among the tools an agent is offered, not in an error message. A refusal that names what it protects has already told you what exists. **Groups only add.** A person can be in several groups, and their access is the union of what those groups grant, worked out field by field and operation by operation. Adding someone to a group can only give them more. There are no deny rules to reason about, and no group is special: inside an app there is no administrator mode that skips the rules. **A rule about rows is a rule, not a filter.** "Only the deals I own" is applied by the database on every read. It is not a saved view somebody can switch off. ## Two products, one definition The people who design an app and the people who use it need different things, so gtable is two products. The **Studio** is where a builder works. They define tables and fields, create groups, decide what each group may see and do, and invite people. The **app** is where those people work: the Data grid, the Interface, and the Connection surface for their agents. Both work from one definition, and that definition lives beside the app's data, in the app's own database. Serving an app never asks the Studio anything. That gives a simple test of whether the split is real: switch the Studio off, and every app keeps working. ## What an invited person gets Someone invited into an app lands on the data they are allowed to see, in a grid made for working: saved views, nested filters, grouping, linked records, and a record panel with comments and history. If the builder allows it, they can describe a screen to the assistant and get it, built on the same data and bound by the same rules. And they can connect their own agent, which works as them, with exactly their access. That last part is the subject of the next post: [how an agent gets exactly your permissions](/blog/agents-with-your-permissions). ## Where this stands gtable is not open yet. The permission compiler, the grid, the Studio and the machine surfaces run today, in our own hands. Sign-up, pricing and email do not exist yet. This blog is where the rest will be written up as it gets built.