AppSheet: o que é, o que vem no Workspace e o banco que muda a licença

O AppSheet costuma chegar à empresa sem ninguém pedir. Alguém da operação abre uma planilha de controle no Google Sheets, encontra o menu Extensões, clica em AppSheet e, em uma tarde, a planilha virou um aplicativo no celular da equipe. Como o Workspace já está pago, ninguém pensa em licença.

O problema aparece quando o app cresce e alguém sugere tirar os dados da planilha e colocá-los num banco de verdade. Este guia explica o que é o AppSheet, para que serve, como criar e compartilhar um app e o que o plano Core inclui. E vai à pergunta que deveria vir antes de escolher onde os dados vão morar: de quem é a licença que o app vai exigir de todo mundo que o abrir.

O que é o AppSheet?

O AppSheet é a plataforma do Google para criar aplicativos sem programar. Você aponta uma fonte de dados (uma planilha, uma tabela, uma pasta do Drive) e ele lê as colunas, sugere telas, formulários e filtros e entrega um app que roda no navegador, no Android e no iPhone. O AppSheet nasceu como empresa independente e foi comprado pelo Google, que desde então o integrou ao Google Workspace e ao Google Cloud.

Diferente de uma ferramenta de formulário, o app do AppSheet grava de volta na fonte: quando o técnico registra uma visita no celular, a linha aparece na planilha. Por cima disso entram regras (quem vê o quê), automações (mandar um e-mail quando um pedido for aprovado, gerar um PDF, chamar outro sistema) e, nos planos mais altos, recursos de IA como leitura de texto em foto.

Ele é do mesmo gênero do Power Apps, da Microsoft, mas as regras de cobrança não são as mesmas. No Power Apps, o que pesa é o tipo de conector; já explicamos essa lógica no artigo sobre a licença do Power Apps que cai sobre quem usa o app. No AppSheet, o que pesa é a licença de quem criou o app, e é isso que este texto destrincha.

Para que serve o AppSheet na prática?

Serve para tirar da planilha compartilhada e do grupo de WhatsApp os processos que já têm dono, mas ainda não têm sistema. O ponto doce é o processo operacional, repetitivo, com poucas regras e muitos registros: o tipo de coisa que hoje vive numa aba com 40 colunas e uma legenda de cores que só uma pessoa entende.

• Inspeção e vistoria de campo: checklist no celular, foto, assinatura e localização gravadas na mesma linha.
• Controle de estoque e ativos: leitura de código de barras para dar entrada e saída de material.
• Solicitações e aprovações: compras, reembolsos, férias, com e-mail automático para o aprovador.
• Agenda e visitas comerciais: roteiro do dia, registro da visita e próximo passo, com mapa.
• Chamados internos: manutenção, TI, facilities, com status e responsável visíveis para todos.

Onde ele não brilha: sistemas com regra de negócio pesada, alto volume de transações por segundo ou experiência de marca voltada ao consumidor final. Aí o desenvolvimento tradicional costuma sair mais barato no tempo de vida do produto, tema do nosso texto sobre a saída do low-code que ninguém desenha.

Como criar um app no AppSheet?

O caminho mais curto parte da própria planilha. O roteiro abaixo é o que usamos para um primeiro protótipo, e cabe numa tarde.

1. Arrume a fonte antes de abrir o AppSheet

Uma aba por entidade (clientes, visitas, itens), cabeçalho na primeira linha, uma coluna de identificador único e nada de célula mesclada. O AppSheet lê a estrutura da planilha para montar o app; planilha bagunçada vira app bagunçado.

2. Gere o app a partir dos dados

No Google Sheets, use Extensões › AppSheet › Criar um app. O editor abre com as tabelas detectadas, os tipos de coluna sugeridos (texto, data, imagem, endereço, referência a outra tabela) e uma primeira versão das telas. Também dá para descrever o app em linguagem natural e deixar o Gemini propor a estrutura.

3. Ajuste tipos, telas e regras

Corrija o tipo de cada coluna, defina o que é obrigatório, crie as visões (lista, mapa, calendário, painel) e as ações. É aqui que um app de demonstração vira ferramenta de trabalho.

4. Teste com um grupo pequeno antes de abrir para todos

Enquanto o app é protótipo, o Google permite convidar até 10 usuários de teste sem custo, e o teste pode durar o tempo que for preciso. Use essa fase para medir quem realmente vai usar o app, e não só para caçar bug: é esse número que vai para a conta de licença.

O AppSheet é gratuito?

Depende do que se chama de gratuito. Há três situações diferentes, e confundir uma com a outra é a origem da maior parte das surpresas:

• Criar e testar: é grátis. O criador usa os recursos básicos sem pagar e pode convidar até 10 usuários de teste para o protótipo.
• Usar com a equipe, dentro do Workspace: muitas edições do Google Workspace já incluem o AppSheet Core. Nesse caso, o custo já está na assinatura do Workspace, desde que o app fique dentro do que o Core cobre.
• Usar com recursos avançados: fontes de dados como bancos SQL, BigQuery e Salesforce, OCR e modelos preditivos pertencem ao Enterprise Plus, que é uma licença à parte.

O Google não publica, na central de ajuda, um preço único do Enterprise Plus para o Brasil: o valor depende do contrato e do canal de compra (direto ou por revenda Workspace). Por isso, este artigo não traz tabela de preço; traz a regra que define quantas licenças a empresa vai precisar, que é o que costuma mudar a conta de ordem de grandeza.

Vale também saber o que o Google não faz: ele afirma que não acrescenta cobrança automática por uso. Se a empresa passar do número de licenças compradas, não chega uma fatura extra, mas o acesso aos apps pode ser restringido depois de meses seguidos de excesso. O risco, portanto, não é a fatura surpresa: é o app parar no meio da operação.

O que o AppSheet Core inclui e o que fica no Enterprise Plus?

O Core já é um plano completo para a maioria dos apps internos. Ele herda tudo do Starter e acrescenta recursos de que um app de operação realmente precisa, como filtros de segurança, papéis de usuário e leitura de código de barras.

Google, AppSheet Help, “How to choose a subscription” e “Subscription, license and usage, and billing FAQ” (2026)

Repare na última linha. Ela não descreve um recurso: descreve uma consequência. E é nela que mora a decisão mais cara do projeto.

Por que a licença de quem cria decide a de quem usa?

Porque essa é, literalmente, a regra escrita pelo Google. Não importa qual licença o usuário tem no Workspace; importa qual licença o criador do app tem.

Na prática, isso cria um efeito de contaminação de cima para baixo. Para usar MySQL ou BigQuery como fonte, o criador precisa ser Enterprise Plus. A partir daí, o app dele passa a pedir Enterprise Plus (ou User Pass) de cada pessoa que o abre, não só de quem desenvolve. O Core incluído no Workspace dos usuários deixa de bastar.

E há um desdobramento menos óbvio: como a regra olha para o criador, e não para os recursos de cada app, um criador Enterprise Plus que monta um app simples sobre planilha tende a gerar a mesma exigência. Por isso, a pergunta de governança não é só “este app precisa de banco?”, mas também “quem deve ser o dono deste app?”.

Qual fonte de dados tira o app do Core?

A conversa que leva o app para fora do Core quase sempre começa com uma boa intenção técnica. A planilha ficou lenta, passou de dezenas de milhares de linhas, alguém editou uma fórmula sem querer, e a recomendação natural é “vamos colocar isso num banco”. Os candidatos mais comuns, e todos do Enterprise Plus, são:

• Banco relacional (MySQL, PostgreSQL, SQL Server, MariaDB, Oracle), inclusive o Cloud SQL do próprio Google, que roda um desses motores.
• BigQuery, quando a empresa quer que o app leia o mesmo dado que alimenta os painéis.
• Salesforce, quando o app é um complemento de campo para o CRM.
• Banco on-premises, quando o dado está no servidor do ERP dentro da empresa.
• OCR e modelos preditivos, que não são fonte de dados, mas caem na mesma regra: são recursos do Enterprise Plus.

Nenhuma dessas escolhas é errada. O erro é tomá-las como decisão de arquitetura, quando são também decisão de licença para toda a base de usuários. Um app usado por 15 pessoas do escritório e outro usado por 300 técnicos de campo têm o mesmo custo técnico de migração para MySQL, mas contas de licença completamente diferentes.

Antes de migrar, vale tentar o que o Core já oferece para a lentidão: sincronização delta, sincronização rápida, cache no servidor e filtros de segurança que fazem cada usuário baixar só as linhas que lhe dizem respeito. Muitas vezes o gargalo é o app baixar a base inteira para todo mundo, e não a planilha em si.

Como compartilhar um app do AppSheet, inclusive com quem é de fora?

Compartilhar é simples: no editor, a opção de compartilhamento pede os e-mails dos usuários (ou, no Enterprise Plus, um grupo do Google) e envia o convite com o link de instalação. Também é possível publicar o app sem login, para qualquer pessoa com o link. O que muda é a contagem.

Para apps com login, cada e-mail da lista conta como um usuário; uma mesma pessoa pode usar até cinco aparelhos sem contar em dobro. Para apps sem login, o Google conta cada aparelho que abre o app como um usuário separado. E a empresa precisa comprar licenças para o total de usuários previstos, autenticados e convidados.

Juntando as duas regras: um app de cadastro de fornecedores, feito por um criador Enterprise Plus e aberto para que os próprios fornecedores preencham, consome licença Enterprise Plus de cada fornecedor que o abrir no mês. Um app público sem login, aberto em centenas de celulares de clientes, pode contar centenas de usuários.

Para esse caso, o Google tem um plano próprio, o Publisher Pro, cobrado por app publicado e não por usuário, pensado para apps públicos sem autenticação. Se o app nasce para o público externo, é por ele que a conversa deve começar, e não pela licença dos funcionários.

O AppSheet funciona offline?

Sim. Os apps do AppSheet guardam uma cópia dos dados no aparelho, permitem consultar e registrar informações sem sinal e sincronizam as alterações quando a conexão volta. É um dos motivos pelos quais ele é tão usado em vistoria, obra, logística e visita comercial.

Dois cuidados: o que o app baixa para o aparelho precisa caber nele (outro motivo para usar filtros de segurança e baixar só o necessário), e duas pessoas editando o mesmo registro offline geram conflito na volta. Defina no desenho quem é o dono de cada registro e o problema quase desaparece. No Core, a criptografia dos dados no aparelho já está incluída, o que importa quando o celular é pessoal.

Quais os erros mais comuns ao adotar o AppSheet?

1. Escolher a fonte de dados pela técnica e esquecer a licença. A migração da planilha para o banco é decidida pelo TI em uma reunião, e a conta de licença de 200 usuários chega meses depois.
2. Deixar o app no nome de quem tem a licença mais alta. Como a exigência segue o criador, o dono do app é uma decisão de custo, não um detalhe de quem clicou primeiro.
3. Contar só os funcionários. Fornecedores, clientes e parceiros externos usam a licença do dono do app, e apps sem login contam aparelhos, não pessoas.
4. Ignorar a regra do mês-calendário. Uma licença usada uma vez fica com o usuário até o fim do mês; acesso esporádico de muita gente custa como acesso diário.
5. Tratar o protótipo como produção. Os 10 usuários de teste gratuitos são para validar, não para operar; o app que “sempre foi de graça” para a equipe toda já deveria estar licenciado.
6. Não ter dono nem documentação. App criado por uma pessoa, na conta dela, sem registro de regras e fontes, vira refém quando ela sai da empresa.

O AppSheet vale a pena?

Para a empresa que já paga o Google Workspace e tem processos presos em planilha, vale muito: o Core resolve a maioria dos apps internos sem custo extra e coloca um sistema no ar em dias. Ele deixa de valer, ou passa a exigir conta cuidadosa, quando o app precisa de banco corporativo para muitos usuários ou vai ser aberto ao público.

Regras de licença das páginas de ajuda do AppSheet citadas no artigo (2026). Cenários elaborados pela Alliance.

A comparação com o Power Apps também ajuda a decidir. Lá, cada conector premium impõe licença a quem usa o app; aqui, a régua é o criador. Em empresas que têm as duas plataformas, vale escolher pela casa onde os dados já estão, Microsoft 365 ou Google Workspace, e não pela ferramenta que a equipe conheceu primeiro.

Por onde começar: a pergunta antes da fonte de dados

Antes de abrir o editor, responda três perguntas por escrito. Elas cabem numa página e evitam a maior parte das revisões de orçamento.

1. Quem cria e é dono do app? Defina uma conta de dono (de preferência institucional, não pessoal) e a licença dela.
2. Quem vai usar, por mês? Conte funcionários, externos com login e, se o app for aberto, aparelhos.
3. Onde os dados vão morar daqui a um ano? Se a resposta for banco SQL, BigQuery ou Salesforce, faça a conta do Enterprise Plus para toda a base agora, não depois.

Se as respostas apontarem para o Core, comece pelo protótipo com até 10 usuários e cresça sem medo. Se apontarem para o Enterprise Plus, compare o custo anual com o de um sistema sob medida antes de decidir. A consultoria de low-code e no-code da Alliance faz essa triagem: o que fica no Core, o que justifica o Enterprise Plus e o que deveria ser desenvolvimento tradicional. E se a dúvida for maior que um app, o diagnóstico de marketing gratuito mostra em que ponto a tecnologia e a automação da empresa estão travando o resto.