---
title: "One app definition. Every way to use it."
description: "The grid, the screens people build on it and the connection any agent can use, all over one app definition and one permission compiler."
language: en
canonical: https://grid82.com/product
source: Grid82 website
---
# One app definition. Every way to use it.

The grid, the pages people build on it, the assistant, the API and MCP all run on one database and one permission compiler. Each person sees only their own slice.

## A grid with views, nested filters and grouping

The first thing an invited person sees is the data they may see, in a grid.

- **Views.** Several saved views per table, each with its own filters, sorting, grouping, hidden fields and row height.
- **Filters that nest.** "In negotiation, and either high priority or over 50k" is one filter, not three.
- **Relations.** Linked records, lookups and rollups, because a real business has more than one table.
- **The record panel.** Every field of a record in one place, with comments and a history of who changed what.
- **Spreadsheet habits.** Copy and paste between cells, undo with ⌘Z, CSV in and out, summaries under each column.

## Screens that belong to the people using them

Describe the screen you want and the assistant writes it on your data: a dashboard, a board, a form for one job. The builder decides, role by role, who may make pages of their own.

- **Same data, same rules.** A page reads through the permissions of the person looking at it. A page cannot show what its viewer could not see in the grid.
- **Sandboxed.** Generated page code runs on a separate origin, in a sandboxed frame, with no access to your session.
- **Versions.** Every published page keeps its versions, so a page somebody broke is one step from working again.

## Nothing hidden behind an export button

Everything the screen can do, a script or an agent can do too, as the person whose credential it holds.

- **MCP.** One server per suite, at `https://<suite>.grid82.app/mcp`, with OAuth so a client connects with nothing but the address.
- **REST.** Every app has a REST API with an OpenAPI document generated for the caller: it describes only the tables and fields that caller can read.
- **One registry.** The API, the MCP tools and the command-line tool are generated from one list of routes, so they cannot drift apart. The command-line tool is not published yet.

The details are in the [documentation](https://grid82.com/docs) and on the [agents page](https://grid82.com/agents).

## Builders design, invited people use

The Studio is where a builder designs apps: tables and fields, user roles and what each may see and do, the people invited. Apps are grouped into suites, and each suite has one address, one login page and one list of people.

- **Organisations, suites, apps.** An organisation holds suites, a suite holds apps. The same human in two suites is two separate accounts, so nothing can leak between them.
- **View as.** A builder can look at an app exactly as one of its roles sees it, before anybody is invited.
- **Two assistants.** One in the Studio that builds with you, one in every app that works inside the person's own access.

## Built so the rules cannot be skipped

- **A database per app.** Each app's definition and data live together in its own SQLite database on Cloudflare's network.
- **One permission compiler.** The grid, the API, MCP and the assistant all ask the same compiler. There is no second path to the data.
- **Apps do not need the Studio.** Serving an app never calls the Studio. Switch the Studio off and every app keeps working.
- **Undo.** Every write is recorded, by whoever made it, and can be undone from the record's history.